On 15/03/2009, Henri Yandell <flame...@gmail.com> wrote: > On Sun, Mar 15, 2009 at 11:20 AM, sebb <seb...@gmail.com> wrote: > > On 15/03/2009, Henri Yandell <flame...@gmail.com> wrote: > >> On Sun, Mar 15, 2009 at 5:08 AM, sebb <seb...@gmail.com> wrote: > >> > On 15/03/2009, Henri Yandell <flame...@gmail.com> wrote: > >> > >> >> > >> > >> >> Anyway... amusing play stuff when I should be sleeping; and not > >> >> believing FindBugs too much. Need to try for Double, Long etc; maybe > >> >> this lore holds more true there. Plus maybe it's Apple's JVM being > >> >> interesting and this holds true in Sun land. > >> > > >> > I think you treat equal times unfairly - they are neither slower nor > faster. > >> > Also, the variables are not used, so the compiler could well optimise > >> > the loop away. > >> > >> > >> Agreed, but I didn't see an equals at any point in the output so it's > >> again lost in the noise. > >> > >> I think I'd have seen radical differences if the compiler was > >> optimizing the loop away as one or both of the numbers would have been > >> 0 (or at least constant). > >> > > > > I get very different results using your code and the one in the link > > (I editted that to provide the loop count on the command line). > > > > The other test consistently showed that valueOf was faster. > > > It's a good article - though they're testing different things. That > code is testing that 0 can be created many times etc which should be > faster for valueOf's cache. Mine was testing every number.
Sorry, I'd not noticed that. Oops! That changes things to much closer to what you are seeing. Using -server seems to make things worse for both cases, at least until the loop count reaches 5-10 million. > Reading that caching only happens for a small set of numbers, it makes > sense that valueOf is going to be worse, and that smaller sets are > faster. So I think findbugs is being quite wrong in this case unless > Integers are in the cache of 255 cached values. It'd be a surprise if > Long/Float/Double were faster as you'd not expect them to have large > caches, but you would expect Char (due to predominant ascii use), > Short, Boolean and Byte to be worth using valueOf on. Something to > test :) In Sun JDK 1.5: Short and Long have the same cache range as Integer. Float and Double don't cache. Character: <=127 Byte -128 - +127 i.e. all of them. > > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
