logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Logger.trace(String, Object...) and extra APIs
Date Mon, 10 Nov 2014 06:11:02 GMT
So... should we add 1, 2, and 3 arg methods. That would be a lot of new
methods, but I prefer that to the ton of throw away arrays being created
now...

Gary

On Tue, Oct 28, 2014 at 8:14 AM, Gary Gregory <garydgregory@gmail.com>
wrote:

> On Tue, Oct 21, 2014 at 10:45 AM, Remko Popma <remko.popma@gmail.com>
> wrote:
>
>> It may be worthwhile to see if there other places where we create a lot
>> of objects. (Not sure, would a profiler help here?) The API change would be
>> a lot of work for perhaps relatively little savings. There may still be
>> many internal places where we can get a lot of bang for our buck when small
>> changes give large savings.
>>
>> Are there any PatternConverters that create StringBuilders when they
>> could just use the one that is passed in as an argument (I'm aware of
>> AbstractStyleNameConverter, perhaps there are others)?
>>
>> Also, in PatternLayout.toSerializable, (where we create the StringBuilder
>> that is passed to all the converters to build the pattern-based message),
>> we use the default StringBuilder constructor. This has a buffer of only 16
>> chars. If this is not sufficient, it will be doubled, then doubled again,
>> etc. We should make that buffer at least 256 or 512 chars, I would guess
>> that many messages are more than 64 chars, so this minor change can save at
>> least two char[] object constructions and buffer copies.
>>
>> One application at work got a nice performance boost when we started
>> using a thread-local StringBuilder instead of creating new instances.
>> Perhaps that is also a good idea for PatternLayout.toSerializable()?
>>
>
> That would be an interesting experiment! One could then also imaging
> having methods typed to StringBuilder but that does not help because you
> must toString a StringBuilder to get useful data out of it so you end up
> creating lots of String objects anyway. So then I wonder if we should have
> our own AbstractStringBuilder implementation that gives us access to the
> underlying char[] that we can then log internally (accounting for the count
> of course)... It's all talk until sometime sits down with a profiler... ;-)
>
> Gary
>
>>
>> On Tue, Oct 21, 2014 at 10:51 PM, Gary Gregory <garydgregory@gmail.com>
>> wrote:
>>
>>> IIRC we discussed adding methods like:
>>>
>>> org.apache.logging.log4j.Logger.trace(String, Object)
>>> org.apache.logging.log4j.Logger.trace(String, Object, Object)
>>> org.apache.logging.log4j.Logger.trace(String, Object, Object, Object)
>>>
>>> to avoid creating arrays for 'small' #'s of args.
>>>
>>> Why did we decide not to do it? Too many APIs?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
View raw message