This looks like a real mem saver
static {
logger.registerMessage("messagekey", new StringFormattedMessage("%s"));
}
public void run(String param) {
logger.debug("messagekey", param);
Ofcourse doc should say what is thread safe and how to use. Unrelated
but same idea: We saved a few milliseconds and few 1,000 objects by
caching SimpleDateFormats - but can only used the shared instances for
format and not parse
On 10/6/2012 12:23 AM, Paul Benedict wrote:
> After reading this email, it occurred to me that Messages/Formats are
> typically static. Once instantiated, there is really no need to
> instantiate it over and over.
>
> Rather than specifying the Class<?>, perhaps there should be a
> registration feature. Maybe like this:
>
> public class MyApp {
> public static Logger logger;
> static {
> logger.registerMessage("messagekey", new
> StringFormattedMessage("%s"));
> }
>
> public void run(String param) {
> logger.debug("messagekey", param);
> }
> }
>
> Paul
>
> On Fri, Oct 5, 2012 at 1:03 PM, Ralph Goers
> <ralph.goers@dslextreme.com <mailto:ralph.goers@dslextreme.com>> wrote:
>
> I updated ReflectionComparison to include comparing creating the
> object via "new" and via reflection.
>
> Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average
> per iteration: 0.000000019 seconds
> Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds
> Average per iteration: 0.000000171 seconds
>
> So reflection definitely is noticeably slower, but this is only
> going to occur after filtering has passed and is probably a good
> tradeoff for avoiding calling "new" in the application until it is
> actually needed. For example, there would probably be hundreds of
> logging calls that wouldn't create an object because filtering
> didn't pass, thus compensating for the extra cost of allocating
> the objects and immediately discarding them. OTOH, doing
>
> if (logger.isDebugEnabled()) {
> logger.debug(new StringFormattedMessage(format, param));
> }
>
> would probably perform better than
>
> logger.debug(StringFormattedMessage.class, format, param);
>
> Ralph
>
>
> On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
>
>> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rgoers@apache.org
>> <mailto:rgoers@apache.org>> wrote:
>>
>> Yup. That is what I would expect. However, it probably
>> requires a Message that has a constructor that accepts a
>> Throwable and an object array, which means we would probably
>> want a new interface as a marker.
>>
>>
>> So would reflection be used at runtime to instantiate the
>> message? Wouldn't that be a performance hit?
>>
>> We could just provide APIs in AbstractLogger for the built-in
>> message classes that do the instance creation w/o reflection.
>>
>> Thoughts?
>>
>> Gary
>>
>>
>> Ralph
>>
>> Sent from my iPad
>>
>> On Oct 4, 2012, at 7:18 PM, Paul Benedict
>> <pbenedict@apache.org <mailto:pbenedict@apache.org>> wrote:
>>
>>> Ooops. I meant this:
>>>
>>> logger.debug(Class<? extends Message> m, Throwable t,
>>> Object... messageParams);
>>>
>>> The point was to pass in the Class of the Message so it
>>> doesn't get instantiated unless logging is going to occur.
>>>
>>> Paul
>>>
>>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory
>>> <garydgregory@gmail.com <mailto:garydgregory@gmail.com>>
wrote:
>>>
>>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict
>>> <pbenedict@apache.org <mailto:pbenedict@apache.org>>
wrote:
>>>
>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory
>>> <garydgregory@gmail.com
>>> <mailto:garydgregory@gmail.com>> wrote:
>>>
>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict
>>> <pbenedict@apache.org
>>> <mailto:pbenedict@apache.org>> wrote:
>>>
>>> Ralph,
>>>
>>> This is actually a discussion you and I had
>>> a while back when I was trying to figure out
>>> how to use String.format(). I like the model
>>> now of specifying the message class...
>>> however...
>>>
>>> It does seem a bit unseemly to instantiate
>>> an xxxMessage object that may never get
>>> used. I'd rather just pass in the Class<?>
>>> and let the logger instantiate it only if it
>>> is going to log something. The only downside
>>> is then configuring the actual class.
>>>
>>> Thoughts?
>>>
>>>
>>> So instead of:
>>>
>>> this.logger.debug(new
>>> StringFormattedMessage(format, values), t);
>>>
>>> I would do:
>>>
>>> this.logger.debug(StringFormattedMessage.class,
>>> t, format, values);
>>>
>>>
>>> I was thinking of adding this signature:
>>> logger.debug(Message m, Throwable t, Object...
>>> messageParams);
>>>
>>> Thoughts?
>>>
>>>
>>> Pardon me for being dense, but how does that help in the
>>> case of my examples?
>>>
>>> Thank you in advance for clarifying,
>>> Gary
>>>
>>>
>>> Paul
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com
>>> <mailto:garydgregory@gmail.com> | ggregory@apache.org
>>> <mailto:ggregory@apache.org>
>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com <mailto:garydgregory@gmail.com> |
>> ggregory@apache.org <mailto:ggregory@apache.org>
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
|