使用中间变量而不是array.length会使你的for循环变得更快吗？

Android文档中的"性能提示"部分有一个非常大胆的主张:

one()是比较快的.它将所有内容都拉到局部变量中,避免了查找.只有阵列长度才能提供性能优势.

它引用此代码段:

int len = localArray.length;

for (int i = 0; i < len; ++i) {
    sum += localArray[i].mSplat;
}

---

这让我感到很惊讶,因为localArray.length只是访问一个整数,如果你使用一个中间变量,你必须再次执行相同的步骤.我们真的在说一个只需要x代替的中间变量y.x更快吗？

我看了一下这个问题是关于同样的想法但是使用了一个arraylist及其后续的.size()方法.这里的共识似乎是没有区别,因为方法调用可能只是内联到整数访问(这正是我们在这里的场景).

所以我接受了字节码,看看是否可以告诉我任何事情.

给出以下源代码:

public void MethodOne() {
    int[] arr = new int[5];
    for (int i = 0; i < arr.length; i++) { }
}

public void MethodTwo() {
    int[] arr = new int[5];
    int len = arr.length;
    for (int i = 0; i < len; i++) { }
}

我得到以下字节码:

public void MethodOne();
    Code:
        0: iconst_5
        1: newarray       int
        3: astore_1
        4: iconst_0
        5: istore_2
        6: iload_2
        7: aload_1
        8: arraylength
        9: if_icmpge     18
        12: iinc          2, 1
        15: goto          6
        18: return

public void MethodTwo();
    Code:
        0: iconst_5
        1: newarray       int
        3: astore_1
        4: aload_1
        5: arraylength
        6: istore_2
        7: iconst_0
        8: istore_3
        9: iload_3
        10: iload_2
        11: if_icmpge     20
        14: iinc          3, 1
        17: goto          9
        20: return

它们在以下说明中有所不同:

方法一

6: iload_2
7: aload_1
8: arraylength
9: if_icmpge     18
12: iinc          2, 1
15: goto          6
18: return

方法二

9: iload_3
10: iload_2
11: if_icmpge     20
14: iinc          3, 1
17: goto          9
20: return

现在,我不是100%确定我必须如何解释,8: arraylength但我认为这只是表明您正在访问的字段.第一种方法加载索引计数器和数组并访问该arraylength字段,而第二种方法加载索引计数器和中间变量.

我使用JMH(10次预热,10次迭代,5次分析)对两种方法进行了基准测试,这给出了以下基准测试结果:

c.m.m.Start.MethodOne    thrpt        50  3447184.351    19973.900   ops/ms
c.m.m.Start.MethodTwo    thrpt        50  3435112.281    32639.755   ops/ms

这告诉我差异可以忽略不计.

---

关于什么是Android文档声称在循环条件中使用中间变量？

1> Dragan Bozan..：

---

你误解了文档.它们并不是指你所描述的内容(虽然我不怪你,但他们应该把更多的精力投入到这些文档:)).

它将所有内容都拉到局部变量中,避免了查找.

通过避免查找,它们引用字段与本地变量访问成本.访问该字段(mArray在文档中的示例中)需要this先加载,然后根据固定的偏移量加载字段this.

过了一会儿,JIT可能会弄清楚发生了什么并优化了字段访问(如果字段不是volatile或在循环中发生了某种其他形式的同步)并重写代码以便所有参数都参与循环在CPU寄存器和缓存中访问/更改,直到循环结束.

通常,JIT可能更有可能确定与存储在局部变量中的引用相比,优化对从字段引用的数组长度的访问是否安全.假设我们有以下循环:

for (int i = 0; i < array.length; ++i) {
    process(array[i]);
}

如果array是一个字段并process调用数千行复杂代码,那么JIT可能会发现很难检查array字段是否在循环中的某处更改以引用具有不同长度的其他数组.

显然,在这种情况下检查局部变量是否更改(三行代码)要容易得多.

---

有趣的是,OP忽略了另一个语句,即在没有JIT的系统上,使用`for(Foo a:mArray)`循环的方法`two()`(文档有三个以`zero()`开头的方法)更快.这更令人困惑,因为它依赖于实际的编译器,生成的字节代码是否在`one()`和`two()`之间有任何区别.我闻到了深奥的优化技巧......