It would not be easy to force all of these lists to have some
particular concrete implementation ("FinalArrayList") although some
could. I can repeat the analysis with a larger number of runs just to
be sure, but the speedup was seen in the context of the actual
compiler rather than a microbenchmark, so I believe there is some
reality to it.
Dan
On Thu, Jun 4, 2009 at 11:58 PM, Ray Cromwell<[email protected]> wrote:
> This test is invalid due to the way Class Hierarchy Analysis works in
> Hotspot (similar to type-tightening in GWT). Since you never touch any
> other List implementations, Hotspot will know that List == ArrayList
> and all method calls are monomorphic. Try adding a LinkedList to your
> test and see what happens. In JDK5 this would foul up the
> optimizations. In a complex case like the compiler, it's bound to
> pick up other implementations of list, even if it's just
> Collections.unmodifiableList().
>
> Microbenchmarking Hotspot is never really effective and fraught with
> problems. You also might want to try the -server JVM flag which
> sometimes makes a huge difference.
>
> -Ray
>
>
> On Fri, Jun 5, 2009 at 6:35 AM, Amit Manjhi <[email protected]> wrote:
>> I completely agree with Scott here. It's hard to believe that there will be
>> a consistent 3% improvement just by using an explicit index. The change is
>> very much compiler/JVM dependent. And even if there were the case currently,
>> the next compiler/JVM could very easily fix this.
>>
>> Since I was surprised by the result, I wrote up a simple micro-benchmark
>> that repeats this test with Integer lists of varying sizes. I ran it with
>> openjdk and did not see *any* performance difference. I have attached the
>> quick-and-dirty code and included the sample results at the end.
>>
>> Amit
>>
>> =============================================
>> Here are sample results: java -cp . -Xmx1500M com.test.Test
>>
>> iteration with 1000 elements
>> long way: 1, short way: 1
>> long way: 1, short way: 1
>> long way: 2, short way: 3
>> long way: 1, short way: 3
>> long way: 2, short way: 5
>> long way: 9, short way: 7
>> long way: 1, short way: 2
>> long way: 10, short way: 2
>> long way: 0, short way: 2
>> long way: 0, short way: 1
>>
>>
>> iteration with 1000000 elements
>> long way: 11, short way: 12
>> long way: 14, short way: 11
>> long way: 20, short way: 20
>> long way: 20, short way: 22
>> long way: 27, short way: 27
>> long way: 28, short way: 30
>> long way: 38, short way: 42
>> long way: 37, short way: 42
>> long way: 45, short way: 45
>> long way: 46, short way: 49
>>
>>
>> iteration with 10000000 elements
>> long way: 124, short way: 124
>> long way: 125, short way: 125
>> long way: 280, short way: 262
>> long way: 282, short way: 262
>> long way: 349, short way: 345
>> long way: 348, short way: 344
>> long way: 529, short way: 499
>> long way: 566, short way: 663
>> long way: 530, short way: 508
>> long way: 530, short way: 508
>>
>>
>>
>> On Thu, Jun 4, 2009 at 1:58 PM, Aaron Steele <[email protected]> wrote:
>>>
>>> Do'h! Yeah, using the name 'ints' probably wasn't a good choice here.
>>> Looks like I should re-read Item 56: Adhere to generally accepted
>>> naming conventions. :)
>>>
>>> On Thu, Jun 4, 2009 at 1:09 PM, Alex Rudnick <[email protected]> wrote:
>>> >
>>> > Yeesh, pardon. That's an ArrayList called "ints" of Integers, not
>>> > containing ints. I retract that statement!
>>> >
>>> > On Thu, Jun 4, 2009 at 4:04 PM, Alex Rudnick <[email protected]> wrote:
>>> >> Sounds like boxing/unboxing overhead, in that case!
>>> >>
>>> >> What if you tried that with an array of native ints?
>>> >>
>>> >> On Thu, Jun 4, 2009 at 3:47 PM, Aaron Steele <[email protected]>
>>> >> wrote:
>>> >>>
>>> >>> So item 46 in Effective Java says that there shouldn't be a
>>> >>> performance penalty using the nice for loops. But the following test
>>> >>> in Eclipse on my machine (MacBook Pro, Intel Core Duo, 2.16 GHz) shows
>>> >>> a performance penalty.
>>> >>>
>>> >>> Given an ArrayList called ints with 1 million Integers, this takes 31
>>> >>> milliseconds:
>>> >>> for (int i = 0, size = ints.size(); i < size; i++)
>>> >>> ints.get(i).intValue();
>>> >>>
>>> >>> And this takes 76 milliseconds:
>>> >>> for (Integer i : ints)
>>> >>> i.intValue();
>>> >>>
>>> >>> What am I missing? Probably just some super naive testing on my part.
>>> >>> :)
>>> >
>>> > --
>>> > Alex Rudnick
>>> > swe, gwt, atl
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Sent from Piedmont, CA, United States
>>>
>>>
>>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
