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
