Как дорого в Java отливать от int к коротким

Question

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

Answer 1

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

Answer 2

Оставляя в стороне философские аргументы и оправдания ...

Прежде всего short - это специальный тип данных. Java на самом деле не нравится short. Java на самом деле действительно любит int, потому что стек JVM использует 32-битные регистры . И short - это 16-битный тип данных (int = 32-битный).

Из-за 32-битной структуры всякий раз, когда java перемещает короткое замыкание в стек, он автоматически конвертируется в целое число. Итак, первое, о чем стоит задуматься, действительно ли я хочу использовать short в java? Они приходят действительно с ценой. Вот почему вы редко когда-либо увидите использование short типов данных в исходном коде jdk.

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

Вы можете найти некоторые характеристики в этой статье , но i2s, к сожалению, нет в списке. Это должно занять менее 20 нс.

Answer 3

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

Answer 4

Ниже приведен тест для длинного случая, но он может быть легко адаптирован для короткого случая. Приведение int к long в этом примере примерно на 5% медленнее, чем просто передача long.

Интересно, что вызов метода с использованием неявного приведения происходит медленнее, благодаря самому приему

без приведения: PT0.141517096S С литой: PT0.148024511S С неявным приведением: PT0.159904349S

@Test
public void testPerformance(){
    long sum =0L;
    long timeCallWithImplicitCast =0;
    long timeCallWithLong =0;
    long timeCallWithCast =0;


    for(int j=0;j<2;j++) {//First run warm-up
        timeCallWithCast=0;
        timeCallWithLong=0;
        timeCallWithImplicitCast=0;
        for (int i = 0; i < 10_000_000; i++) {
            long s1 = System.nanoTime();
            sum += shift(i);//Call with int implicit cast
            long e1 = System.nanoTime();
            timeCallWithImplicitCast += (e1 - s1);
        }
        for (int i = 0; i < 10_000_000; i++) {
            long s3 = System.nanoTime();
            sum += shift((long) i);//Call with cast long
            long e3 = System.nanoTime();
            timeCallWithCast += (e3 - s3);
        }
        for (int i = 0; i < 10_000_000; i++) {
            long l = (long) i;
            long s2 = System.nanoTime();
            sum += shift(l);//Call with long
            long e2 = System.nanoTime();
            timeCallWithLong += (e2 - s2);
        }
    }
    System.out.println("With no cast      : "+ Duration.ofNanos(timeCallWithLong));
    System.out.println("With cast         : "+Duration.ofNanos(timeCallWithCast));
    System.out.println("With implicit cast: "+Duration.ofNanos(timeCallWithImplicitCast));

}

protected long shift(long index){
    return index << 4;
}

Answer 5

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

Answer 6

Зачем вам это нужно? Я не думаю, что это сильно повлияет на производительность, но имейте в виду диапазон нужного вам типа данных:

int:   -2,147,483,648 to 2,147,483,647
short: -32,768 to 32,767

Answer 7

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