问题描述
|
这是代码段：
https://gist.github.com/987751
对我来说，它的时间是这样的：
java-客户端：
for循环：23
方法调用时间：19
java-服务器：
for循环：0＃，比预期的快
方法调用：48＃更慢-预期？
因此，第一个问题将是“为什么它比客户端VM慢”
而且我猜下一个问题是“方法调用方式是否有可能获得超0ms的加速（几乎相同的代码）？”
我还假定尽管有这种怪异，但即使使用匿名类等，热点通常运行得也快得多？
谢谢！
-罗杰-
解决方法
有关如何调整Hotspot的两种口味的所有信息：
客户端已针对快速启动进行了调整。 JIT立即“几乎”编译方法。
在假定是长时间调整服务器实例的生命周期内，已针对服务器的较高吞吐量进行了调整。它允许解释器在JIT编译方法之前将方法运行更长的时间（收集使用情况统计信息）。然后（我相信）它会执行更具侵略性的优化……这需要更长的时间。
相关答案：“ java -server”和“ java -client”之间的真正区别？
顺便说一下，它是同时运行客户端和服务器模式的Hotspot JVM。 AFAIK，差异是由于这两种模式选择了不同的默认JVM调整/配置参数。
因此，第一个问题将是“为什么它比客户端VM慢”
我不知道。
客户端模式可能会启用特定的优化，从而确实有助于（高度人工的）基准测试。也许服务器模式优化之一实际上是针对此（高度人为）基准的反优化。如果您真的想知道，请让JIT编译器转储本机代码并进行详细分析。 （但是我认为这是浪费时间。）
而且我猜下一个问题是“方法调用方式是否有可能获得超0ms的加速（几乎相同的代码）？”
这很容易。优化器已经发现方法调用不会影响其他任何东西，并且已经优化了该调用。然后也可以优化循环。
我还假定尽管有这种怪异，但即使使用匿名类等，热点通常运行得也快得多？
我不认为你应该做任何事。
但是，我也不认为您的微基准测试对真实程序有任何有意义的意义。一般而言，微基准测试往往会产生误导，您的基准测试有缺陷（例如，已被优化的循环），并且似乎并未测试典型的（编写良好的）Java程序会做的事情。
如果您确实担心HotSpot两种模式的相对性能，则应在实际数据上运行并评估应用程序的性能。
...以及为什么服务器JVM选择看似更差的东西？
优化器旨在优化实际程序，而不是微基准测试，它们会花费时间来做奇怪的事情，这些事情与有用的计算没有任何相似之处。并非所有优化都在所有情况下都是有益的，并且您可能遇到了某种极端情况。
但这仅在您看到实际应用程序中发生相同事件时才有意义。
最后，您没有提供有关JVM版本，平台和硬件的任何详细信息。这些事情可能会对相对的绩效指标产生巨大的影响。