При обновлении циклов for до циклов for-each в нашем приложении я наткнулся на множество таких «шаблонов»:
for (int i = 0, n = a.length; i < n; i++) {
...
}
вместо
for (int i = 0; i < a.length; i++) {
...
}
Я вижу, что вы повышаете производительность для коллекций, потому что вам не нужно вызывать метод size() в каждом цикле. А с массивами??
Вот и возник вопрос: array.length дороже ли обычной переменной?
Нет, вызов array.length является O(1) или операцией с постоянным временем.
Поскольку .length является (действует как) public final членом array, доступ к нему не медленнее, чем к локальной переменной. (Это сильно отличается от вызова такого метода, как size())
Современный JIT-компилятор, скорее всего, сразу же оптимизирует вызов .length.
Вы можете убедиться в этом, просмотрев исходный код JIT-компилятора в OpenJDK или заставив JVM выгрузить скомпилированный JIT собственный код и изучить код.
Обратите внимание, что могут быть случаи, когда компилятор JIT не может этого сделать; например
array.length не может быть O (1) и по-прежнему занимает больше времени, чем int len = array.length; i < len;, который также будет O (1)?
- person Grant Wagner; 30.07.2009
.length. [нужна цитата]
- person xehpuk; 28.04.2015
javac ничего не оптимизировалось. Я мало знаю о JIT-компиляторах.
- person xehpuk; 15.02.2019
У меня было немного времени за обедом:
public static void main(String[] args) {
final int[] a = new int[250000000];
long t;
for (int j = 0; j < 10; j++) {
t = System.currentTimeMillis();
for (int i = 0, n = a.length; i < n; i++) { int x = a[i]; }
System.out.println("n = a.length: " + (System.currentTimeMillis() - t));
t = System.currentTimeMillis();
for (int i = 0; i < a.length; i++) { int x = a[i]; }
System.out.println("i < a.length: " + (System.currentTimeMillis() - t));
}
}
Результаты:
n = a.length: 672
i < a.length: 516
n = a.length: 640
i < a.length: 516
n = a.length: 656
i < a.length: 516
n = a.length: 656
i < a.length: 516
n = a.length: 640
i < a.length: 532
n = a.length: 640
i < a.length: 531
n = a.length: 641
i < a.length: 516
n = a.length: 656
i < a.length: 531
n = a.length: 656
i < a.length: 516
n = a.length: 656
i < a.length: 516
Примечания:
n = a.length покажет, что он быстрее, чем i < a.length, примерно наполовину, вероятно, из-за сборки мусора (?).250000000, потому что получил OutOfMemoryError в 270000000.Дело в том, что это то, что делают все остальные, вам нужно запускать Java из памяти, и вы все еще не видите существенной разницы в скорости между двумя альтернативами. Потратьте время разработки на то, что действительно важно.
Я сомневаюсь, что есть какая-либо существенная разница, и даже если бы она была, я бы поспорил, что она, вероятно, была оптимизирована во время компиляции. Вы тратите свое время, когда пытаетесь микрооптимизировать подобные вещи. Сначала сделайте код читабельным и правильным, затем, если у вас есть проблемы с производительностью, используйте профилировщик, затем позаботьтесь о выборе лучших структур данных/алгоритмов, если это уместно, затем позаботьтесь об оптимизации части, которые выделяет ваш профилировщик.
.length на несколько порядков.
- person Grant Wagner; 30.07.2009
Длина массива хранится как переменная-член массива (не то же самое, что элемент) в Java, поэтому выборка этой длины является операцией с постоянным временем, такой же, как чтение переменной-члена из обычного класса. Многие старые языки, такие как C и C++, не сохраняют длину как часть массива, поэтому вам нужно сохранить длину до начала цикла. Вам не нужно делать это в Java.
В этом случае, почему бы вам не сделать обратный цикл:
for (int i = a.length - 1; i >= 0; --i) {
...
}
Здесь есть 2 микрооптимизации:
Возможно, было бы немного быстрее сохранить его в переменной. Но я был бы очень удивлен, если бы профилировщик указал на это как на проблему.
На уровне байт-кода получение длины массива выполняется с помощью байт-кода arraylength. Я не знаю, медленнее ли это, чем байт-код iload, но разницы не должно быть достаточно, чтобы заметить.
Этот ответ с точки зрения C #, но я думаю, что то же самое относится и к Java.
В C# идиома
for (int i = 0; i < a.length; i++) { ...}
распознается как перебор массива, поэтому проверка границ не выполняется при доступе к массиву в цикле, а не при каждом доступе к массиву.
Это может быть или не быть распознано с помощью кода, такого как:
for (int i = 0, n = a.length; i < n; i++) { ...}
or
n = a.length;
for (int i = 0; i < n; i++) { ...}
Какая часть этой оптимизации выполняется компилятором по сравнению с JITter, я не знаю, и, в частности, если она выполняется JITter, я ожидаю, что все 3 будут генерировать один и тот же собственный код.
Тем не менее, первая форма также, возможно, более удобочитаема для людей, поэтому я бы сказал, что придерживаюсь ее.
Array.length является константой, и JIT-компилятор должен это учитывать в обоих случаях. Я ожидаю, что результирующий машинный код будет одинаковым в обоих случаях. По крайней мере, для серверного компилятора.
