Эффективность кода Java с примитивными типами

Я бы предпочел первый, а не второй, потому что он не позволяет переменным цикла не мешать остальной части кода метода. Поскольку они не видны вне цикла, вы не сможете случайно к ним обратиться позже.

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

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

Если вы не уверены, вы всегда можете скомпилировать его и посмотреть, что произойдет. Сделаем два класса, f1 и f2, для двух версий:

$ cat f1.java
public class f1 {
  void f() {
    for(int i = 0 ; i < 99999;i++) {
      for(int j = 0 ; j < 99999;j++) {
      }
    }
  }
}

$ cat f2.java
public class f2 {
  void f() {
    int i, j;
    for(i = 0 ; i < 99999;i++) {
      for(j = 0 ; j < 99999;j++) {
      }
    }
  }
}

Скомпилируйте их:

$ javac f1.java
$ javac f2.java

И декомпилируйте их:

$ javap -c f1 > f1decomp
$ javap -c f2 > f2decomp

И сравните их:

$ diff f1decomp f2decomp
1,3c1,3
< Compiled from "f1.java"
< public class f1 extends java.lang.Object{
< public f1();
---
> Compiled from "f2.java"
> public class f2 extends java.lang.Object{
> public f2();

В байт-коде нет абсолютно никакой разницы.

ЭТО. НЕТ. СДЕЛАТЬ. РАЗНИЦА.

Прекратите микрооптимизацию. Эти маленькие уловки не заставляют программы работать намного быстрее.

Сконцентрируйтесь на оптимизации общей картины и написании удобочитаемого кода.

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

Остерегайтесь опасностей микробенчмаркинга !!!

Я взял код, обернул метод снаружи и запустил его 10 раз в цикле. Результаты:

50, 3, 
3, 0, 
0, 0, 
0, 0, 
....

Без фактического кода в циклах компиляторы могут определить, что циклы не делают полезной работы, и полностью их оптимизировать. Учитывая измеренную производительность, я подозреваю, что эта оптимизация могла быть произведена javac.

Урок 1: Компиляторы часто оптимизируют код, который выполняет бесполезную «работу». Чем умнее компилятор, тем больше вероятность того, что подобное произойдет. Если вы не учитываете это в способе кодирования, эталонный тест может быть бессмысленным.

Затем я добавил следующее простое вычисление в оба цикла if (i < 2 * j) longK++; и заставил тестовый метод возвращать окончательное значение longK. Результаты:

32267, 33382,
34542, 30136,
12893, 12900,
12897, 12889,
12904, 12891,
12880, 12891,
....

Очевидно, мы остановили компиляторы, оптимизирующие цикл. Но теперь мы видим эффекты разогрева JVM (в данном случае) первых двух пар итераций цикла. Первые две пары итераций (один вызов метода), вероятно, выполняются исключительно в интерпретируемом режиме. И похоже, что третья итерация может работать параллельно с JIT. К третьей паре итераций мы, скорее всего, будем запускать чистый собственный код. И с тех пор разница между синхронизацией двух версий цикла - это просто шум.

Урок 2: всегда учитывайте эффект прогрева JVM. Это может серьезно исказить результаты тестов, как на микро, так и на макроуровне.

Заключение - как только JVM разогревается, между двумя версиями цикла нет заметной разницы.

Второй хуже.

Почему? Поскольку переменная цикла находится вне цикла. i и j будут иметь значение после завершения цикла. Обычно это не то, что вам нужно. Первый охватывает переменные цикла, поэтому он виден только внутри цикла.

Я бы предположил, что нет абсолютно никакой разницы в эффективности для любой полуприличной реализации JVM.

Нет, это вообще не имеет значения (по скорости). Оба они компилируются в один и тот же код. И не происходит никакого распределения и освобождения, как сказал MasterGaurav.

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

Единственная небольшая крошечная незначительная разница (кроме области видимости) заключается в том, что в первом примере память, выделенная для i и j, может быть повторно использована для других переменных. Следовательно, JVM будет выделять меньше слотов памяти для этого метода (ну, вы сохранили некоторые биты)

Во-первых, да, ваш учитель ошибается, второй код не лучше. Что значит лучше? Это связано с тем, что в любом нормальном цикле операции внутри тела цикла являются частью, отнимающей много времени. Таким образом, Code 2 - это просто микро-оптимизация, которая не увеличивает скорость (если таковая имеется), чтобы оправдать плохую читаемость кода.

Второй лучше по скорости.

Причина в том, что в первом случае область действия j ограничена внутренним циклом for.

Таким образом, в момент завершения внутреннего цикла память для j освобождается и снова выделяется для следующей итерации внешнего цикла.

Поскольку выделение и освобождение памяти занимают некоторое время, даже если она находится в стеке, производительность первой из них ниже.

Есть еще один аспект, который очень важен для двух разных версий:

В то время как в варианте 2 создаются только два временных объекта (i и j), вариант 1 создает 100000 объектов (1 x i и 999999 x j). Возможно, ваш компилятор это оптимизирует, но вы не можете быть уверены в этом. Если его не оптимизировать, сборка мусора будет вести себя значительно хуже.