On 11/18/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Bernd Fondermann wrote: > > On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> ---- > >> Output code 2 from jdk 1.4 > >> > String s2 = s + "test" + s1 + "test" + i; > >> ---- > >> Output code 2 from jdk 1.5 > >> > String s2 = (new StringBuilder()).append(s).append("test") > >> > .append(s1).append("test").append(i).toString(); > >> > >> I also ran with jdk5 that code in a loop of 1 million iterations using > >> foo = "foo" and bar = "bar" (this is FAR from any realistic scenario). > > > > <sigh> Microbenchmarking, again! ;-) > > Could it be you are testing loop optimization here? ;-) > > I started the message with a worning about this ;-) > Anyway I did a lot of micro changes to try to understand wether the > microtest was realistic or not. As an example if I concatenate 2 more > tokens in the same line the resulting time is increased by 30%. I also > increased and decreased the loop count and randomly generated the > contents of the variables. Times was always comparable: +/- 20% > > > What also is totally obscured by the whole discussion, is to set in > > relation the max performance difference of the different logging > > implementations discussed here - the "delta" - to the cost of the > > rest of the method. Only if delta is a significant cost (a "hot spot") > > it is worth talking about optimizing it before optimizing everything > > else. > > > > Bernd > > I agree on this. > > I just wanted to show more detail about the "old good practices" we all > know vs new jvm/jdk. > > Imho it is really interesting to see that in jdk 1.5 the string > concatenation is replaced by StringBuilder by default and this way is > even better than using the StringBuffer.perhaps one plan would be to factor out logging calls into a JamesLogEnabled class. the idea would be abstract all logging calls into a superclass. this would perform a null check on the logger and the isXXXEnabled. it would also provide pre-parameterized calls: info(Object one) info(Object one, Object two) ... (yes, i know that this is close to ceki's forth generation bridging logging interfaces and i make no claim of originality) this would mean all string building code is in one place whilst also increasing the readibility of the code. yes, i know that there probably are concerns about including mixin's as part of inheritance hierarchies but this is done already in james and the alternative is bytecode engineering. since IMAP uses an experimental logging scheme and i'm having to add lots of logging to understand my email issues, maybe i'll add something along those lines to my local version...
see https://issues.apache.org/jira/browse/JAMES-703 i plan to use this system for future IMAP logging improvement patches (unless there are complaints). - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
