Подтвердить что ты не робот

Читаемость и производительность

Недавно мы провели дискуссию о влиянии локальных переменных на производительность и читаемость кода Java. Некоторые из моих коллег говорят о том, что подобные объявления

new DoSomethingCmd(new SelectionContext(context, keys), infoStuff.getCurrentRole().getRole_id()).execute(getResultContainer());

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

final SelectionContext selectionContext = new SelectionContext(context, keys);
final String roleId = infoStuff.getCurrentRole().getRole_id();
final DeleteSomethingCmd deleteSomethingCmd = new DeleteSomethingCmd(selectionContext,roleId);
deleteSomethingCmd.execute(getResultContainer());

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

Спасибо за ваш вклад.

4b9b3361

ОТВЕТЫ

Ответ 1

Единственное, что делает "оптимизированная" версия, это то, что в стеке несколько переменных меньше, что немного увеличивает потребление памяти. Эффективность должна быть тщательно измерена (Google, как проверить проблему), но я серьезно сомневаюсь, что она имеет какой-то заметный эффект.

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

В этом случае читаемость должна выиграть день.

EDIT: Во всяком случае, если вы используете правильный отступ, я не считаю, что две версии слишком отличаются в терминах удобочитаемости:

new DoSomethingCmd(
    new SelectionContext(context, keys),
    infoStuff.getCurrentRole().getRole_id()
    ).execute(getResultContainer());

Преимущество этого текста в том, что у вас нет определенных переменных (selectionContext, roleId), которые больше не нужны (поэтому, когда вы снова читаете метод, они не смешиваются с более "постоянными" переменными). Во всяком случае, это открыто для интерпретации; суть в том, что вам не стоит беспокоиться об оптимизации, если у вас нет мотива для этого.

Кроме того, есть некоторые рекомендации по программированию на Java, которые дают вам действительно полезные трюки, которые действительно помогают вам (v.g. using StringBuilder для объединения строк).

Ответ 2

Правильны ли они утверждать это?

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

Ответ 3

Время человека в миллионы раз дороже компьютерного времени.

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

Даже тогда, совершенно бессмысленно оптимизировать, как будто компилятор глуп.

Не забывайте! Преждевременная оптимизация - это корень всего зла.

Ответ 4

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

Ответ 5

Я вижу несколько вызовов функций здесь

  • два вызова new

  • a SelectionContext конструктор

  • вызов getRole_id()

  • a DeleteSomethingCmd конструктор

  • вызов GetResultContainer()

  • вызов элемента execute() DeleteSomethingCmd

Итак, предположим, что вы запускаете это gazillion раз, и за это время вы берете несколько образцов стека.

Как вы думаете, вероятность того, что образец стека не отобразит вас внутри одного из этих вызовов функций?

Чрезвычайно низкий, не так ли? Вероятно, гораздо меньше одного процента?

Итак, даже если вы сделали код на этом уровне бесконечно быстрым, что бы это спасло вас?

Перспектива - это все.

Ответ 6

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

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