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
