短时间的性能/内存的好处是否因下播而无效？

Question

我正在编写一个大规模的应用程序，在这个应用程序中，我试图尽可能地节省内存并提高性能。因此，当我有一个我知道的字段只有0- 10或-100 - 100的值时，我尝试使用short数据类型而不是int。

然而，这对代码的其余部分意味着，当我调用这些函数时，我必须将简单的ints降为short。

方法签名

public void coordinates(short x, short y) ...

方法调用

obj.coordinates((short) 1, (short) 2);

在我的代码中，这一切都是这样的，因为文本被视为ints，而不是根据函数参数自动向下转换或输入。

因此，一旦发生这种下拉式转换，性能或内存增益是否会显著增加？还是转换过程如此有效，以至于我仍然可以获得一些收益？

Answer 1

在32位平台上使用short和int并没有任何性能上的好处，除了short[]和int[]之外，即使这样，缺点通常也超过了优点。

假设您运行的是x64、x86或ARM-32：

• 在使用时，16位短路被存储在整数寄存器中，这些寄存器要么32位，要么64位长，就像ints一样。也就是说，当短时间在使用时，相对于int，您没有获得内存或性能的好处。
• 在堆栈上，16位短路被存储在32位或64位的“插槽”中，以保持堆栈对齐(就像ints一样)。对局部变量使用短裤和INT不会带来性能或内存方面的好处。
• 当作为参数传递时，当短路被推到堆栈上时，它们会自动加宽到32位或64位(与刚刚被推送的ints不同)。实际上，这里的代码性能略低，与使用int相比，内存占用(代码)稍大一些。
• 当存储全局(静态)变量时，这些变量会自动展开，占用32位或64位插槽，以保证指针(引用)的对齐。这意味着在全局(静态)变量中使用短裤和INT没有任何性能或内存好处。
• 在存储字段时，这些字段位于堆内存中的结构中，该结构映射到类的布局。在这个类中，字段自动填充到32位或64位，以维护堆上字段的对齐。对于字段和INT，使用短裤无法获得性能或内存方面的好处。

您将看到的唯一的好处，使用短裤和国家工作队是在情况下，您分配了一个数组。在这种情况下，N个短路数组的长度大约是N个In数组的一半。

除了在一个热循环中将变量放在一起所带来的性能好处(在大量的短路中使用复杂但本地化的数学)之外，您将永远不会看到使用短裤相对于INT的好处。

在所有其他情况下--例如用于字段、全局值、参数和局部变量的短片，除了可以存储的位数之外，短和INT之间没有区别。

与往常一样，我的建议是，在使代码更难阅读、更人为地限制代码之前，尝试对代码进行基准测试，看看内存和CPU瓶颈在哪里，然后解决这些瓶颈。

我强烈怀疑，如果您曾经遇到这样的情况，即您的应用程序正在遭受使用ints而不是短裤的痛苦，那么您早就已经放弃Java，转而使用更少的内存/CPU运行时，所以提前完成所有这些工作都是徒劳无功。

Answer 2

据我所见，转换本身应该没有运行时成本(是否使用short而不是int实际上提高了性能，这还有待商榷，并取决于应用程序的具体情况)。

请考虑以下几点：

public class Main {
    public static void f(short x, short y) {
    }

    public static void main(String args[]) {
        final short x = 1;
        final short y = 2;
        f(x, y);
        f((short)1, (short)2);
    }
}

main()的最后两行编译为：

  // f(x, y)
   4: iconst_1      
   5: iconst_2      
   6: invokestatic  #21                 // Method f:(SS)V

  // f((short)1, (short)2);
   9: iconst_1      
  10: iconst_2      
  11: invokestatic  #21                 // Method f:(SS)V

正如你所看到的，它们是相同的。转换在编译时进行。

Answer 3

从int文字到short的类型转换发生在编译时，不影响运行时性能。