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. 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 :) Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
