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 <remko.po...@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 <garydgreg...@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 <garydgreg...@gmail.com> > wrote: > >> On Tue, Oct 21, 2014 at 10:45 AM, Remko Popma <remko.po...@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 <garydgreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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
