Fwd: No for each loop comment?

[Vitaly Davidovich]

Bytecode isn't that interesting when discussing peak performance of jit'd
code.  Do you have assembly dumps?

The only noteworthy aspect of the bytecode is that the enhanced for loop
version is slightly bigger,  and combined with other code in some method,
may inhibit inlining.

Speaking of which, have you tried running the jmh benchmarks with tiered
compilation disabled? If not,  please do as it may introduce variance/noise.

Sent from my phone
On Sep 29, 2014 1:58 PM, "Paul Benedict" <pbenedict at apache.org> wrote:

> Bytecode output courtesy of Mikael Ståldal:
>
> With standard loop:
>
>   private static boolean contains(org.apache.logging.log4j.Marker,
> org.apache.logging.log4j.Marker...);
>     Code:
>        0: iconst_0
>        1: istore_2
>        2: aload_1
>        3: arraylength
>        4: istore_3
>        5: iload_2
>        6: iload_3
>        7: if_icmpge     29
>       10: aload_1
>       11: iload_2
>       12: aaload
>       13: astore        4
>       15: aload         4
>       17: aload_0
>       18: if_acmpne     23
>       21: iconst_1
>       22: ireturn
>       23: iinc          2, 1
>       26: goto          5
>       29: iconst_0
>       30: ireturn
>
>
> With for-each:
>
>   private static boolean contains(org.apache.logging.log4j.Marker,
> org.apache.logging.log4j.Marker...);
>     Code:
>        0: aload_1
>        1: astore_2
>        2: aload_2
>        3: arraylength
>        4: istore_3
>        5: iconst_0
>        6: istore        4
>        8: iload         4
>       10: iload_3
>       11: if_icmpge     34
>       14: aload_2
>       15: iload         4
>       17: aaload
>       18: astore        5
>       20: aload         5
>       22: aload_0
>       23: if_acmpne     28
>       26: iconst_1
>       27: ireturn
>       28: iinc          4, 1
>       31: goto          8
>       34: iconst_0
>       35: ireturn
>
>
>
> Cheers,
> Paul
>
> On Mon, Sep 29, 2014 at 11:31 AM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> I think Paul's email already has jmh output.
>>
>> I looked at the generated asm on 7u60 x64 linux, and didn't see any
>> material difference.
>>
>> Paul, have you or anyone else looked at the machine code diffs between
>> the two? Looking at timing is useful, but it's possible to get caught up in
>> noise; the generated assembly should provide more conclusive data on
>> whether any real difference is there or not.
>>
>> On Mon, Sep 29, 2014 at 11:21 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>>> On 09/29/2014 03:29 PM, Paul Benedict wrote:
>>> > Open JDKers, I am forwarding an email to get some clarification. It's
>>> been
>>> > a common understanding that foreach should perform no differently than
>>> the
>>> > equivalent for-loop . However, some fellow developers claim there is a
>>> > noticable difference in their microbenchmarking. Can you help explain
>>> what
>>> > is really going on? It's either the case there is a true difference (a
>>> > result that would surprise me) or the results are within a margin of
>>> error
>>> > that make the results insignificant. Please advise.
>>>
>>> The actual code that such a forEach loop generates is this:
>>>
>>>     private int forLoop(final int[] array) {
>>>         int result = 0;
>>>         int[] a = array;
>>>         int len = a.length;
>>>         for (int i = 0; i < len; i++) {
>>>             int element = a[i];
>>>             result ^= element;
>>>         }
>>>         return result;
>>>     }
>>>
>>> If you get different timings for this one, then the measurements are
>>> suspect.
>>>
>>> Java microbenchmarking is notoriously difficult.  Please try to use
>>> jmh; you'll get better and easier to interpret results.
>>>
>>> Andrew.
>>>
>>>
>>> http://openjdk.java.net/projects/code-tools/jmh/
>>>
>>>
>>
>