拳击会导致性能问题吗？
我正在开发一个项目，其中我们正在生成一种编译为 java 的语言。我们使用的框架（xtext）在其生成的代码中大量使用了装箱。 具体来说，如果您有这样的语句：
int i = 1;
int j = 2;
int k = i + j;
那么编译后的代码如下所示：
IntegerExtensions.operator_plus(((Integer)i), ((Integer)j))
现在，在我正在处理的项目中，在某些情况下，特定的基本二进制操作将非常常见（尤其是增量和比较）。
我的问题是：这会成为性能问题吗？还是 JIT（或类似的智能 JVM 功能）会简单地意识到发生了什么并解决所有问题？
请在发帖前阅读：我对收到“你不应该关心，让它可读”的回复不感兴趣。这段代码是生成的，我根本不关心生成的代码的可读性。我真正关心的是我们不会因此而受到重大的性能影响。
谢谢
I'm working on a project in which we are producing a language which compiles to java. The framework we are using (xtext) makes prolific use of boxing in its generated code.
Specifically, if you have a statement like:
int i = 1;
int j = 2;
int k = i + j;
Then the compiled code looks like:
IntegerExtensions.operator_plus(((Integer)i), ((Integer)j))
Now, in the project I'm working on, there are certain situations where particular basic binary operations are going to be extremely common (especially increments and comparisons).
My question is: is this going to be a problem in terms of performance, or will JIT (or similarly intelligent JVM features) simply realize what's going on and fix it all?
PLEASE READ BEFORE POSTING: I'm not interested in getting responses saying "you shouldn't care, make it readable". This code is generated, and I simply don't care about the readability of the generated code. What I do care about is that we don't take a significant performance hit from this.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这实际上会产生影响。当转换为
Integer时，它将使用Integer.valueOf(int n)方法将int转换为Integer。此方法将检查该值是否在缓存范围内（-128 到 127），如果不在，则会创建 new Integer(n)影响量可能很大或很少，你必须测试一下自己。
This can in fact have an impact. When the cast to
Integeroccurs it will convert theinttoIntegerusingInteger.valueOf(int n)method. This method will check to see if the value is within the cache range (-128 to 127) and if it is not it will createnew Integer(n)The amount of an impact may be a lot or little, you would have to test yourself.
说它导致性能问题取决于您所说的问题。您所说的问题可能取决于代码要解决的问题类型。
此答案中有一个部分对其进行了总结，并且还提供了自动装箱指南的链接，其中提到：
这是一个 具体示例，其中基准测试重点关注 int/Integer 自动装箱
To say that it causes performance issues is dependent on what you'd call an issue. And what you'll call an issue is probably dependent on what kind of problems the code will be solving.
There's a section in this answer that sums it up, and also provides a link to the Autoboxing guide, which mentions:
And here's a specific example with benchmarks focusing on int/Integer autoboxing
根据我的经验得出的一些观察结果：
装箱通常确实会降低应用程序的性能。它的引人注目程度取决于所实现算法的性质。是否值得修复以及哪里只有分析器和您的预期成本效益比才能告诉您。
装箱通常确实会增加应用程序的内存使用量。就我而言，这非常非常重要 - 可能比性能更重要。
Java 中的
int占用 4 到 8 个字节（取决于 JVM 实现）的 32 位范围内存。在 64 位系统上，Integer将占用 20 到 24 个字节 - 并且您仍然需要对它的引用。对于处理大型数组的应用程序来说，其内存需求很容易增加四倍 (x4)，甚至更糟。在这种情况下，拳击可以区分“它有效”和“它不起作用” - 给定计算机上只能拥有这么多内存。尽管内存匮乏的应用程序通常也会变慢，但性能甚至没有进入讨论。
也就是说，对象确实有一个有用的优点：有一种使用
null表示“不存在任何值”的本机方法。A few observations from my experience:
Boxing in general does decrease the performance of an application. How noticeable it is depends on the nature of the implemented algorithms. Whether it's worth fixing and where is something only a profiler and your expected cost-to-benefit ratio can tell you.
Boxing in general does increase the memory usage of an application. This, as far as I am concerned, is very important - probably more important than performance.
An
intin Java takes up 4 to 8 bytes (depending on the JVM implementation) of memory for 32 bits of range. AnIntegerwill take up 20 to 24 bytes on an 64-bit system - and you still need a reference to it. For an application that processes large arrays that could easily quadruple (x4) its memory requirements - or worse.In this case, boxing can make the difference between "It works" and "It does not work" - there is only so much memory you can have on a given computer. Performance does not even come into the discussion, although, memory-starved applications will generally be slower as well.
That said, objects do have a useful advantage: there is a native way to say "no value exists" by using
null.简单地说：测试它。
制作一个简单示例的两个版本并测量所需的时间。然后您就会知道性能的确切差异以及您是否负担得起。
Simply put: test it.
Make the two versions of a simple example and measure the time it takes. Then you'll know the exact difference in performances and if you can afford it.