Бокс вызывает проблемы с производительностью? - PullRequest
Новая
       4

Бокс вызывает проблемы с производительностью?

5 голосов
/ 12 декабря 2011

Я работаю над проектом, в котором мы создаем язык, который компилируется в Java. Фреймворк, который мы используем (xtext), широко использует бокс в сгенерированном коде. В частности, если у вас есть заявление вроде: 

int i = 1;
int j = 2;
int k = i + j;

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

IntegerExtensions.operator_plus(((Integer)i), ((Integer)j))

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

У меня вопрос: это будет проблемой с точки зрения производительности, или JIT (или аналогичные интеллектуальные функции JVM) просто поймут, что происходит, и все исправят?

ПОЖАЛУЙСТА, ПРОЧТИТЕ ПЕРЕД ПОСТАВКОЙ: я не заинтересован в том, чтобы получать ответы, в которых говорится: «Вам все равно, сделайте это читабельным». Этот код сгенерирован, и мне просто наплевать на читаемость сгенерированного кода. Что меня беспокоит, так это то, что мы не получим значительного снижения производительности от этого.

Спасибо

Ответы [ 4 ]

4 голосов
/ 12 декабря 2011

Это может оказать влияние. Когда произойдет приведение к Integer, оно преобразует int в Integer, используя метод Integer.valueOf(int n). Этот метод проверяет, находится ли значение в пределах диапазона кэша (от -128 до 127), и если нет, оно создаст new Integer(n)

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

3 голосов
/ 12 декабря 2011

Несколько замечаний из моего опыта:

  1. Бокс в целом снижает производительность приложения. Насколько это заметно, зависит от характера реализованных алгоритмов. Стоит ли это исправлять и , где - это то, что может сказать только профилировщик, и ожидаемое соотношение цены и выгоды.

  2. Бокс в целом делает увеличение использования памяти приложением. Насколько мне известно, это очень важно - возможно, важнее, чем производительность.

    int в Java занимает от 4 до 8 байт (в зависимости от реализации JVM) памяти для 32-битного диапазона. Integer займет 64–24 байта в 64-битной системе - и вам все еще нужна ссылка на него. Для приложения, которое обрабатывает большие массивы, которые могут легко в четыре раза (х4) удовлетворить свои требования к памяти - или еще хуже.

    В этом случае бокс может иметь значение между «Это работает» и «Это не работает» - на данном компьютере может быть только столько памяти. Производительность даже не обсуждается, хотя приложения с нехваткой памяти, как правило, будут работать медленнее.

Тем не менее, объекты do имеют полезное преимущество: существует родной способ сказать "не существует значения" с помощью null.

3 голосов
/ 12 декабря 2011

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

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

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

А вот конкретный пример с тестами, ориентированными на int / Integer autoboxing

Простой вопрос: насколько дорого стоит автобокс int / Integer типов?

Простой ответ: 15 наносекунд забокс.

1 голос
/ 12 декабря 2011

Проще говоря: протестируйте его.

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

...