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