Может ли компилятор оптимизировать создание ссылок?

Question

Возьмем, например, цикл, как это:

public boolean method(){ 
    for (int i = 0; i < 5; i++) { 
     if (this.object.getSomething().getSomeArray().get(i).getArray().size() > 0) 
      return false; 
    } 
    return true; 
} 

Каждый get метод просто возвращает частный атрибут. Более читаемый вариант того же кода будет:

public boolean method(){ 
    MySomeArray mySomeArray = this.object.getSomething().getSomeArray(); 
    for (int i = 0; i < 5; i++) { 
     MyArray array = mySomeArray.get(i).getArray(); 
     if (array.size() > 0) 
      return false; 
    } 
    return true; 
} 

Другая версия:

public boolean method(){ 
    MySomeArray mySomeArray = this.object.getSomething().getSomeArray(); 
    MyArray array; 
    for (int i = 0; i < 5; i++) { 
     array = mySomeArray.get(i).getArray(); 
     if (array.size() > 0) 
      return false; 
    } 
    return true; 
} 

Я знаю, что в теории компиляторы могут оптимизировать многие вещи, и в этом случае (на мой взгляд) три версии цикла должны быть оптимизированы точно таким же машинным кодом. Насколько я прав, или будет разница в количестве числа инструкций, выполненных в трех версиях?

Answer 1

Если MySomeArray, а также все другие классы, участвующие в цепочке разыменования, находятся в нижней части их соответствующих иерархии классов, то HotSpot будет легко перевести все эти вызовы виртуальных функций в «простые» (не виртуальные)) вызывает метод, известный как сайт мономорфного вызова оптимизация.

Это может произойти, даже если классы не являются классами листьев. Важно то, что на каждом сайте вызова отправляется только один тип объекта.

С неуверенностью виртуальных функций в стороне, компилятор может продолжить встроить все вызовы, а затем выполнить любые дальнейшие оптимизации, например, подъем в вашем случае. Конечные значения, извлеченные из цепочки разыменования может быть связан с регистрами и т.д.

Обратите внимание, что большая часть выше подлежит весь код пути быть свободным от любого происходит, перед тем отношения к действиям других потоков , На практике это в основном означает отсутствие переменного доступа и без synchronized блоков (в пределах вашего собственного кода, а также всего кода, вызванного вашим кодом).

Answer 2

Проблема в том, что вы делаете предположения, которые компилятор не может сделать.

Вы знаете, что this.object.getSomething().getSomeArray() не меняется каждый раз вокруг цикла, но компилятор не знает об этом. Тем более, что другие потоки могут потенциально изменять эти переменные одновременно ...

Answer 3

Напишите тестовый пример, который использует этот метод, и print the generated assembly code при его запуске. Затем вы можете проверить, сколько звонков включено. Я скептически отношусь к тому, что компилятор способен объединить их все, но компилятор JIT может удивить.

Я бы предпочел более читаемую версию в любом случае, потому что она более читаема.

Answer 4

С достаточным вложением, компилятор может действительно Подъемник Метод вызывается из цикла, очень похожий на то, что вы делали вручную во втором и третьем примерах. Детали того, будет ли это на самом деле делать это, полностью зависят от поведения и размера рассматриваемых методов, а также от сложности JIT.

Я написал ваш пример и протестировал его с помощью суппорта, и все методы имеют эквивалентные тайминги. Я не проверял сборку, так как это более активно, но я буду держать пари, что они почти эквивалентны.