The difference is due to the way ArrayList is implemented and how it interferes with how HotSpot works, here's an old flamy thread from 2005 where I comment on this and how to fix it; http://www.eclipsezone.com/eclipse/forums/t18140.html?start=0
I was able to speed up some ArrayList code by 20x with some simple changes, the relevant analysis: "Casting to ArrayList won't work if there are any subclasses of ArrayList loaded into the VM. The problem is this: AbstractList returns an Iterator (Itr) with a reference to a AbstractList via a hidden anonymous inner class reference. Then, the Itr class invokes outerClass.get(index). Because "outerClass" is of type AbstractList, and because AbstractList has subclasses, Hotspot cannot determine that the get() call can be inlined from ArrayList.get(). So rather than inlining "array[index]", it does an virtual invocation. Casting to ArrayList may or may not help, since if ArrayList itself has any subclasses loaded into the VM, you end up with the same problem. Some Swing classes and JMX classes (javax.management) that come with JDK1.5 subclass ArrayList, and may be loaded anyway because of some VM bootstrap stuff. The only way around this is to prove to HotSpot that an invocation on ArrayList.get() will infact, invoke ArrayList.get() and not SubClass.get(). Try this (it may not work). Subclass ArrayList, call it FinalArrayList. Make the class final. Cast to FinalArrayList and call get(). HotSpot should be smart enough to figure out that since FinalArrayList is subclassed from ArrayList, the get() invocation cannot be anything but the one in its superclass. The "final" declaration is in fact, not needed for this type of analysis (as long as no subclasses of FinalArrayList are loaded), but HotSpot may be dumber than we thought." Later: "In otherwords, without reimplementing Arraylist at all, merely subclassing it and performing no implementation work, I can make it run as fast or faster than FastList, and if I implement my own Iterator which doesn't do anything except cast its internal reference to the Collection into MyArrayList, my indirect iteration can be much faster as well. This should be a lesson as to the performance overhead of everything being virtual. HotSpot is not yet able to determine all cases in which a superclass or interface reference can only be a single (or more) concrete classes and thus inline calls. " There's a bunch of poorly designed areas of the JRE like this. DirectBuffers are another one, where depending on how you construct them, HotSpot cannot determine whether or not to do appropriate 'magic' semantic inlining of some pointer moving methods. (Another discussion where I find a 24x speedup by getting around JRE designs which confuse Hotspot, http://www.javalobby.org/java/forums/t1303.html) Ordinarily, I wouldn't care about the extra abstraction, but collections and buffers are so vitally important from a performance standpoint, they should sacrifice OO design principles where appropriate. -Ray On Fri, Jun 5, 2009 at 2:15 AM, Scott Blum <[email protected]> wrote: > Given that the syntax is more verbose, what kind of performance improvements > are you seeing? If this makes a measurable difference, I have to admit I'm > pretty surprised that the JVM doesn't optimize well something as common as > iterating over an array list. > On Thu, Jun 4, 2009 at 1:54 PM, <[email protected]> wrote: >> >> Reviewers: Lex, scottb, >> >> Description: >> Rewrite loops of the form: >> >> List<T> args; >> for (T arg : args) { >> } >> >> to use an explicit index. This cuts loop overhead by avoiding the need >> to instantiate an Iterator object. >> >> This speeds up a 6-permutation Showcase compile (with -soyc and -style >> PRETTY) by about 3%. >> >> >> >> Please review this at http://gwt-code-reviews.appspot.com/34829 >> >> Affected files: >> dev/core/src/com/google/gwt/core/ext/soyc/impl/StoryRecorder.java >> dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java >> dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java >> dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java >> dev/core/src/com/google/gwt/dev/jjs/impl/CloneExpressionVisitor.java >> dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java >> dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java >> dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java >> dev/core/src/com/google/gwt/dev/js/JsInliner.java >> dev/core/src/com/google/gwt/dev/js/ast/JsVisitor.java >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
