You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2014/10/21 15:51:57 UTC
Logger.trace(String, Object...) and extra APIs
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
Re: Logger.trace(String, Object...) and extra APIs
Posted by Gary Gregory <ga...@gmail.com>.
In the profiling vein, it would be interesting to have a NoopAppender to
better see where time is spent in the framework. This is not to say that
each Appender doesn't deserves its own performance review of course! But
who has the time?! ;-)
Gary
On Mon, Nov 10, 2014 at 1:37 AM, Remko Popma <re...@gmail.com> wrote:
> Should we check in a debugger if this is the cause of most allocations?
> There may be lower hanging fruit that will give more benefit for less
> effort...
>
> Sent from my iPhone
>
> On 2014/11/10, at 15:11, Gary Gregory <ga...@gmail.com> wrote:
>
> 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 <ga...@gmail.com>
> wrote:
>
>> On Tue, Oct 21, 2014 at 10:45 AM, Remko Popma <re...@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 <ga...@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
>
>
--
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
Re: Logger.trace(String, Object...) and extra APIs
Posted by Remko Popma <re...@gmail.com>.
Should we check in a debugger if this is the cause of most allocations? There may be lower hanging fruit that will give more benefit for less effort...
Sent from my iPhone
> On 2014/11/10, at 15:11, Gary Gregory <ga...@gmail.com> wrote:
>
> 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 <ga...@gmail.com> wrote:
>>> On Tue, Oct 21, 2014 at 10:45 AM, Remko Popma <re...@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 <ga...@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
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> 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
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: Logger.trace(String, Object...) and extra APIs
Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@gmail.com>
wrote:
> On Tue, Oct 21, 2014 at 10:45 AM, Remko Popma <re...@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 <ga...@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
Re: Logger.trace(String, Object...) and extra APIs
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 21, 2014 at 10:45 AM, Remko Popma <re...@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 <ga...@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
Re: Logger.trace(String, Object...) and extra APIs
Posted by Remko Popma <re...@gmail.com>.
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()?
On Tue, Oct 21, 2014 at 10:51 PM, Gary Gregory <ga...@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
>