Thanks to Finn and Andreas for looking at this. Given what I see here I'd say the two intern() calls in FOTreeBuilder would better be removed. The Set the namespaces are stored in works with equals() anyway, so I don't see the point of interning the Strings. Or do I miss anything here?
On 28.06.2005 01:07:09 Andreas L. Delmelle wrote: > > -----Original Message----- > > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > > > > > -----Original Message----- > > > From: Finn Bock [mailto:[EMAIL PROTECTED] > > > > <snip /> > > > > > > But since == *is* faster then .equals and I think we can assume that > > > most URIs are in fact from the FO namespace we can get the benefit from > > > both. > > > > > > Measured with jdk1.4.2_02 on winXP: > > > > > > Equal string > > > == 141 > > > .equals 1938 > > > == || .equals 203 > > > > Now THERE's an alternative I can live with... > > > > Everyone happy, including myself :-) > > BTW, have tried with added tests for the case where one of the two strings > isn't interned --create a new String(), looks stupid, but approaches the > situation best--, and noticed a *very* poor performance there. > > (measured on OS X 10.2 - Java 1.4.2) > > Equal strings - both interned > == 252 > .equals 923 > == || .equals 302 > > Different strings - both interned > == 351 > .equals 1306 > == || .equals 1357 > > Equal strings - only one interned > == n/a > .equals 6143 > == || .equals 6164 > > Different strings - only one interned > == n/a > .equals 6140 > == || .equals 6168 > > A one time intern for the non-interned string before the loop --intern the > non-interned string when feeding it to the functions--, leads to figures > like the first case, both for different and equal string values. > > As was to be expected, performing the interning inside the loop is a Very > Bad idea, but that would never have been mine... > > Cheers, > > Andreas Jeremias Maerki
