Какой цикл имеет лучшую производительность? Почему?

В теория объявлять строку внутри цикла - пустая трата ресурсов. Однако в упражняться оба представленных вами фрагмента будут компилироваться до одного и того же кода (объявление вне цикла).

Итак, если ваш компилятор выполняет какую-либо оптимизацию, разницы нет.

В общем, я бы выбрал второй, потому что область действия переменной s ограничена циклом. Выгоды:

• Это лучше для программиста, потому что вам не нужно беспокоиться о том, что 's' снова будет использоваться где-нибудь позже в функции
• Это лучше для компилятора, потому что область действия переменной меньше, и поэтому он потенциально может выполнять больший анализ и оптимизацию.
• Это лучше для будущих читателей, потому что они не будут удивляться, почему переменная 's' объявлена ​​вне цикла, если она никогда не использовалась позже.

Чтобы добавить немного к @ Ответ Эстебана Арайи, они оба потребуют создания новой строки каждый раз в цикле (как возвращаемое значение выражения some Assignment). В любом случае эти строки необходимо собрать с помощью сборщика мусора.

Мне кажется, что нам нужно более детально проработать проблему.

В

s = some Assignment;

не указано, что это за назначение. Если задание

s = "" + i + "";

затем нужно выделить новое жало.

но если это

s = some Constant;

s будет просто указывать на ячейку памяти констант, и, таким образом, первая версия будет более эффективной с точки зрения памяти.

Кажется, мне немного глупо беспокоиться о большой оптимизации цикла for для интерпретируемого языка IMHO.

Ограниченный объем - лучший

Воспользуйтесь вторым вариантом:

for ( ... ) {
  String s = ...;
}

Объем не влияет на производительность

Если вы дизассемблируете код, скомпилированный из каждого (с помощью инструмента JDK javap), вы увидите, что цикл компилируется с одинаковыми инструкциями JVM в обоих случаях. Также обратите внимание, что Брайан Р. Бонди «Вариант №3» идентичен Варианту №1. При использовании более узкой области ничего лишнего не добавляется и не удаляется из стека, и в обоих случаях в стеке используются одни и те же данные.

Избегайте преждевременной инициализации

Единственное различие между этими двумя случаями состоит в том, что в первом примере переменная s инициализируется без необходимости. Это отдельная проблема от места объявления переменной. Это добавляет две потраченные впустую инструкции (для загрузки строковой константы и сохранения ее в слоте кадра стека). Хороший инструмент статического анализа предупредит вас о том, что вы никогда не читаете значение, присвоенное s, а хороший JIT-компилятор, вероятно, пропустит его во время выполнения.

Вы можете исправить это, просто используя пустое объявление (например, String s;), но это считается плохой практикой и имеет еще один побочный эффект, обсуждаемый ниже.

Часто фиктивное значение, такое как null, присваивается переменной просто для того, чтобы скрыть ошибку компилятора о том, что переменная читается без инициализации. Эта ошибка может быть воспринята как намек на то, что область видимости переменной слишком велика и что она объявляется до того, как потребуется получить допустимое значение. Пустые объявления заставляют вас рассматривать каждый путь кода; не игнорируйте это ценное предупреждение, присваивая фиктивное значение.

Сохранить слоты стека

Как уже упоминалось, хотя инструкции JVM одинаковы в обоих случаях, существует тонкий побочный эффект, который позволяет лучше всего на уровне JVM использовать максимально ограниченный объем. Это видно в «таблице локальных переменных» для метода. Подумайте, что произойдет, если у вас есть несколько циклов с объявлением переменных в излишне большой области видимости:

void x(String[] strings, Integer[] integers) {
  String s;
  for (int i = 0; i < strings.length; ++i) {
    s = strings[0];
    ...
  }
  Integer n;
  for (int i = 0; i < integers.length; ++i) {
    n = integers[i];
    ...
  }
}

Переменные s и n могут быть объявлены внутри соответствующих циклов, но поскольку это не так, компилятор использует два «слота» в кадре стека. Если они были объявлены внутри цикла, компилятор может повторно использовать тот же слот, уменьшив размер стека.

Что действительно важно

Однако большинство из этих вопросов несущественны. Хороший JIT-компилятор увидит, что невозможно прочитать начальное значение, которое вы расточительно присваиваете, и оптимизирует назначение. Сохранение слота здесь или там не приведет к поломке вашего приложения.

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

Если вы хотите ускорить циклы, я предпочитаю объявлять переменную max рядом со счетчиком, чтобы не требовалось повторных поисков условия:

вместо

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

я предпочитаю

for (int i = 0, max = array.lenth; i < max; i++) {
  Object next = array[i];
}

Любые другие вещи, которые следует учитывать, уже упоминались, поэтому только мои два цента (см. Сообщение Ericksons)

Greetz, GHad

Я знаю, что это старый вопрос, но я подумал, что добавлю немного, связанное с немного.

При просмотре исходного кода Java я заметил, что некоторые методы, такие как String.contentEquals (дублированные ниже), создают избыточные локальные переменные, которые являются просто копиями переменных класса. Я считаю, что где-то был комментарий, подразумевающий, что доступ к локальным переменным происходит быстрее, чем доступ к переменным класса.

В этом случае «v1» и «v2» кажутся ненужными и могут быть исключены для упрощения кода, но были добавлены для повышения производительности.

public boolean contentEquals(StringBuffer sb) {
    synchronized(sb) {
        if (count != sb.length())
            return false;
        char v1[] = value;
        char v2[] = sb.getValue();
        int i = offset;
        int j = 0;
        int n = count;
        while (n-- != 0) {
            if (v1[i++] != v2[j++])
                return false;
        }
    }
    return true;
}

Когда я использую несколько потоков (50+), я обнаружил, что это очень эффективный способ решения проблем с призрачными потоками, когда я не могу правильно закрыть процесс .... если я ошибаюсь, дайте мне знать, почему Я не прав:

Process one;
BufferedInputStream two;
try{
one = Runtime.getRuntime().exec(command);
two = new BufferedInputStream(one.getInputStream());
}
}catch(e){
e.printstacktrace
}
finally{
//null to ensure they are erased
one = null;
two = null;
//nudge the gc
System.gc();
}