Делает ли добавление локальных переменных в методы медленнее? - PullRequest
5 голосов
/ 23 апреля 2011

Этот вопрос получил всего несколько абзацев ответа.Вот единственное предложение, которое фактически говорит мне о том, что я искал:

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

На самом деле, он прекрасно и полностью отвечает на мой вопрос =)

В отличие от всего, что говорят мне: «Нееет, не задавай этот вопрос».> _ <</p>


Например, если у вас есть метод, и вы меняете его, увеличивая количество локальных переменных, но не внося никаких других изменений, это замедляет метод?Вот пример:

void makeWindow() {
    Display
        .getContext()
        .windowBuilder()
        .setSize(800, 600)
        .setBalloonAnimal(BalloonAnimal.ELDER_GOD.withColor(PUCE))
        .build();
}

или

void makeWindow() {
    DisplayContext dc = Display.getContext();
    WindowBuilder wb = db.windowBuilder();
    BalloonAnimal god = BalloonAnimal.ELDER_GOD;
    BalloonAnimal puceGod = god.withColor(PUCE);
    wb.setSize(800, 600).setBalloonAnimal(puceGod).build();
}

Другой пример:

int beAnExample(int quiche) {
    return areGlobalsEvil?
        quiche * TAU/5:
        highway(quiche, Globals.frenchFrenchRevolution);
}

или

int beAnExample(int quiche) {
    if (areGlobalsEvil) {
        int to5 = TAU/5;
        int result = quiche * to5;
        return result;
    } else {
        Game french = Globals.frenchFrenchRevolution;
        int result = highway(quiche, french);
        return result;
    }
}

Действительно, что яЯ спрашиваю: является ли число локальных переменных такого рода значимым ко времени компиляции метода в байт-код?Если да, то как насчет того, чтобы Hotspot начал работать над ним?

Этот вопрос относится к генератору кода, над которым я работаю.

Ответы [ 5 ]

5 голосов
/ 23 апреля 2011

Простой ответ - нет.Локальные переменные занимают пространство стека времени выполнения.Выделение места для них лишь незначительно увеличивает количество инструкций.Ваши примеры не будут иметь большого значения, поскольку промежуточные вычисления должны временно храниться в стеке, чтобы их можно было использовать позже.Сосредоточьтесь больше на удобочитаемости ваших программ, а не на ненужных микрооптимизациях.

Если вам интересно посмотреть на фактический байт-код класса, исследуйте программу javap.

1 голос
/ 23 апреля 2011

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

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

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

1 голос
/ 23 апреля 2011

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

0 голосов
/ 23 апреля 2011

Скорее всего, это мало что изменит (если вообще что-либо), и "мало" будет незначительным.

Сосредоточьте внимание на том, чтобы ваш генератор был исправным и обслуживаемым, и пустьJava-компилятор (особенно JIT-компилятор) выполняет микрооптимизацию сгенерированного кода.

Обратите внимание, что совет @ Edawg по просмотру байт-кода не обязательно полезен.JIT-компилятор активно оптимизирует нативный код, который он генерирует из байт-кодов.Может быть трудно предсказать, какая из двух последовательностей байт-кода будет быстрее.Конечно, подсчет байт-кодов, вызовов методов и т. Д. Может ввести в заблуждение.

Единственный способ убедиться, что вы генерируете «оптимальный» исходный код Java, - это скомпилировать его и сравнить его с целевой платформой.Даже тогда, есть большая вероятность, что ваши усилия по оптимизации уровня исходного кода будут сведены на нет ... изменениями компилятора JIT.

0 голосов
/ 23 апреля 2011

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

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

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