Объявить объект внутри или вне цикла? - PullRequest
55 голосов
/ 18 декабря 2008

Есть ли снижение производительности для следующего фрагмента кода?

for (int i=0; i<someValue; i++)
{
    Object o = someList.get(i);
    o.doSomething;
}

Или этот код на самом деле имеет больше смысла?

Object o;
for (int i=0; i<someValue; i++)
{
    o = someList.get(i);
    o.doSomething;
}

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

Ответы [ 16 ]

0 голосов
/ 30 июля 2013

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

Object one;
Object two;
Object three;
Object four;
Object five;
try{
for (int i=0; i<someValue; i++)
{
o = someList.get(i);
o.doSomething;
}
}catch(e){
e.printstacktrace
}
finally{
one = null;
two = null;
three = null;
four = null;
five = null;
System.gc();
}
0 голосов
/ 17 апреля 2013

На самом деле передо мной код, который выглядит так:

for (int i = offset; i < offset + length; i++) {
    char append = (char) (data[i] & 0xFF);
    buffer.append(append);
}
...
for (int i = offset; i < offset + length; i++) {
    char append = (char) (data[i] & 0xFF);
    buffer.append(append);
}
...
for (int i = offset; i < offset + length; i++) {
    char append = (char) (data[i] & 0xFF);
    buffer.append(append);
}

Итак, опираясь на возможности компилятора, я могу предположить, что для i будет выделено только одно стек, а для append - одно. Тогда все будет хорошо, кроме дублированного кода.

В качестве примечания, Java-приложения работают медленно. Я никогда не пытался выполнить профилирование в Java, но думаю, что снижение производительности происходит главным образом из-за управления распределением памяти.

0 голосов
/ 01 января 2009

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

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

0 голосов
/ 22 декабря 2008

Как тот, кто поддерживает больше кода, чем пишет код.

Версия 1 является наиболее предпочтительной - для понимания важно поддерживать область видимости как можно более локальной. Такого рода код также легче реорганизовать.

Как обсуждалось выше - я сомневаюсь, что это повлияет на эффективность. На самом деле, я бы сказал, что если область действия будет более локальной, компилятор сможет сделать с ней больше!

0 голосов
/ 18 декабря 2008

В обоих случаях информация о типе для объекта o определяется во время компиляции. Во втором случае o рассматривается как глобальный для цикла for, и в первом случае, умный компилятор Java знает, что o придется быть доступным до тех пор, пока длится цикл, и, следовательно, оптимизирует код таким образом, что в каждой итерации не будет переопределения типа o. Следовательно, в обоих случаях спецификация типа o будет выполняться один раз, а это означает, что единственная разница в производительности будет заключаться в объеме o. Очевидно, что более узкая область действия всегда повышает производительность, поэтому, чтобы ответить на ваш вопрос: нет, нет никакого снижения производительности для первого фрагмента кода; фактически этот фрагмент кода более оптимизирован, чем второй.

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

0 голосов
/ 18 декабря 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...