On 15/03/2009, Henri Yandell <flame...@gmail.com> wrote:
> Findbugs claims we should be writing Integer.valueOf not new Integer
> as it's guaranteed to be faster. The same for the other primitive
> wrappers. I can't let such a statement of surety go untested, so I had
> a play and used the following as a test:
>
> public class Perf {
>
> public static void main(String[] args) throws Exception {
> int count = Integer.parseInt(args[0]);
> for(int i=0; i<100; i++) {
> System.out.println("Valueof faster: " + test(count));
> }
> }
>
> public static boolean test(int count) {
> int step = count / 2;
>
> long ln = System.nanoTime();
> testIntCache(step);
> testIntCache(step);
> ln = (System.nanoTime() - ln)/1000;
> System.out.println("Time for " + count + " valueOf Int: " + ln);
>
> long ln2 = System.nanoTime();
> testIntCreate(step);
> testIntCreate(step);
> ln2 = (System.nanoTime() - ln2)/1000;
> System.out.println("Time for " + count + " new Int: " + ln2);
>
> return ln < ln2;
>
> }
>
> public static void testIntCache(int count) {
> Integer in = null;
> for(int i=0; i<count; i++) {
> in = Integer.valueOf(i);
> }
> }
>
> public static void testIntCreate(int count) {
> Integer in = null;
> for(int i=0; i<count; i++) {
> in = new Integer(i);
> }
> }
>
> }
>
> I found on the Apple JVM 1.5.0_16 that valueOf is faster when:
>
> count = 100 -> Faster about 94% of the time.
> count = 1000 -> Faster about 89% of the time.
> count = 10000 -> Faster about 32% of the time.
> count = 100000 -> Faster about 3% of the time.
>
> valueOf is always much slower for the first loop (building cache
> presumably). Also often much slower on the third loop too. Weird.
> new Int is always much slower on the fourth loop - more so for smaller
> counts. Maybe JIT happening, interesting that it would JIT more for
> new than valueOf if that's the case.
>
> Ideally I should discard these first four loops, but it wouldn't
> change the above too much.
>
> 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.
> 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
