Java короткая, целочисленная, долгая производительность
Я считал ту JVM хранилища, внутренне короткие, целочисленные и длинные как 4 байта. Я считал его из статьи с 2000 года, таким образом, я не знаю, насколько верный это теперь.
Для более нового JVMs, там какое-либо увеличение производительности в использовании короткого по целочисленному/длинному? И та часть реализации изменилась с 2000?
Спасибо
3 ответа
long 64 –9,223,372,036,854,775,808 to 9 ,223,372,036,854,775,807
int 32 –2,147,483,648 to 2,147,483,647
short 16 –32,768 to 32,767
byte 8 –128 to 127
Используйте то, что вам нужно, я думаю, что шорты редко используются из-за небольшого диапазона и в формате big-endian.
Любой прирост производительности будет минимальным, но, как я уже сказал, если для вашего приложения требуется диапазон больше, чем у короткого, используйте int. Тип long может быть слишком большим для вас; но опять же, все зависит от вашего приложения.
Вы должны использовать short только в том случае, если у вас есть проблемы с пространством (памятью), в противном случае используйте int (в большинстве случаев). Если вы создаете массивы и тому подобное, попробуйте, объявив массивы типа int и short. Short будет использовать 1/2 пространства по сравнению с int. Но если вы проведете тесты, основанные на скорости / производительности, вы не увидите практически никакой разницы (если вы имеете дело с массивами), кроме того, единственное, что вы экономите - это место.
Кроме того, один из комментаторов упомянул long, потому что long - это 64 бита. Вы не сможете хранить размер long в 4 байтах (обратите внимание на диапазон long).
Это деталь реализации, но все же верно, что по соображениям производительности большинство JVM будет использовать полное слово (или более) для каждой переменной, поскольку процессоры имеют доступ память в единицах слова. Если бы JVM хранила переменные в единицах подслова и местоположениях, это действительно было бы медленнее.
Это означает, что 32-битная JVM будет использовать 4 байта для краткости (и даже логическое значение), а 64-битная JVM будет использовать 8 байтов. Однако это не относится к элементам массива.
Целочисленные типы хранятся во многих байтах, в зависимости от точного типа :
- byte - 8 бит
- short - 16 бит, signed
- int - 32 бита, signed
- long - 64 бита, signed
Смотрите спецификацию здесь.
Что касается производительности, то это зависит от того, что вы с ними делаете. Например, если вы присваиваете литеральное значение байту или short, они будут преобразованы в int, поскольку литеральные значения по умолчанию считаются ints.
byte b = 10; // upscaled to int, because "10" is an int
Вот почему вы не можете сделать :
byte b = 10;
b = b + 1; // Error, right member converted to int, cannot be reassigned to byte without a cast.
Поэтому, если вы планируете использовать байты или шорты для выполнения циклов, вы ничего не получите.
for (byte b=0; b<10; b++)
{ ... }
С другой стороны, если вы используете массивы байтов или шортов для хранения некоторых данных, вы явно выиграете от уменьшения их размера.
byte[] bytes = new byte[1000];
int[] ints = new int[1000]; // 4X the size
Итак, мой ответ: зависит от ситуации :)