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