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 >>>> 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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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
