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 <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 >
