java System.nanoTime非常慢。是否可以实现高性能的Java分析器？ [英] java System.nanoTime is really slow. Is it possible to implement a high performance java profiler?

问题描述

我做了一个测试，发现我的机器上对System.nanoTime（）的函数调用开销至少为500 ns。

I did a test and found the overhead of a function call to System.nanoTime() is at least 500 ns on my machine.

似乎很难拥有高性能的Java分析器。
对于企业软件，假设一个函数大约需要350秒，并且有12,500,000,000次方法调用。因此，对System.nanoTime（）的调用次数为：
12,500,000,000 * 2 = 25,000,000,000（一个用于开始时间戳，一个用于结束时间戳）
System.nanoTime的总开销为：
500 ns * 25,000,000,000 = 500 * 25000 s = 12500000s。

Seemed that it is very hard to have a high performance java profiler. For enterprise software, suppose a function takes about 350 seconds and has 12,500,000,000 times of method calls. Therefore, the number of calls to System.nanoTime() is: 12,500,000,000 * 2 = 25,000,000,000 (one for start timestamp, one for end timestamp) And the overhead of System.nanoTime in total is: 500 ns * 25,000,000,000 = 500 * 25000 s = 12500000s.

注意：所有来自实际案例的数据。

Note: all data from real case.

获取时间戳的更好方法是什么？

Any better way to acquire the timestamp?

推荐答案

我花了10年时间研究商业Java性能分析器，用于开发和生产。

I've spent 10 years working on commercial Java performance profilers, for use in both development and production.

简短的回答是 - 是的，你是对的。你不能把它拉下来。即使你可以，将一些简单的仪器放入一个经常调用的方法中：

The short answer is - yes, you're right. You can't pull that off. And even if you could, putting anything but trivial instrumentation into a method that is called so frequently can:

• 改变JIT对待的方式代码，因此



• 难以预测性能数据（但从性能调优的角度来看，通常没用）。

• Change the way the JIT treats the code, thus

• skewing your performance numbers in hard to predict (but generally not useful, from a performance tuning standpoint) ways.

（并且让我们不要开始讨论如何在JIT完成之后在基本上紧凑的程序集循环中进行系统调用会影响CPU在预取方面可能做的所有花哨的优化，从而导致<> p>

(and lets not get started on how making a system call in what is basically a tight assembly loop after the JIT is done with it affects all the fancy optimizations the CPU might otherwise be able to do in terms of prefetches, causing an otherwise unnecessary context switch and flushing your L1 cache, etc, etc)

可以慢速调整（或者可能） 很少被称为'会更好吗？）方法。你可以使用仪器，例如，许多JDBC API来捕获数据库问题。

It's OK to instrument slow (or maybe 'infrequently called' would be better?) methods. You can get away with instrumenting, for example, a lot of the JDBC API to catch database issues.

用于实际Java代码的实际性能调优（而不是Java的东西）调用，像网络，文件系统，数据库，...），仪器只是不是真正的方式去。你得到了更多可以理解的结果，但是现在大概7年没有人为性能调整做过线级检测 - 原因相同。

For actual performance tuning of actual Java code (as opposed to stuff Java calls into, like the network, filesystem, database, ...), instrumentation just isn't really the way to go. You get more understandable results, but no-one has done line-level instrumentation for performance tuning for probably 7 years now - same reasons.

相反，商业剖析器使用采样 技术 - 他们会定期进行堆栈跟踪。 JVMTI有一些很好的调用，每隔几毫秒就可以很便宜。然后你假设堆栈跟踪之间的所有时间花费在新堆栈上（显然，这不是真的，但从统计上来说，它可以在非愚蠢的短暂测量期间产生准确的结果） - 而且你已经得到了一些可操作的性能数字，没有疯狂的开销或任何观察者效应。

Instead, commercial profilers use "sampling" technology - they periodically take a stack trace. JVMTI has some nice calls that make it pretty cheap to do so every few ms. Then you assume all the time between stack traces was spent on the new stack (which, obviously, isn't true, but statistically, it produces accurate results over a not-stupidly-short measurement period) - and you've got yourself some actionable performance numbers without crazy overhead or any kind of observer effect.

这篇关于java System.nanoTime非常慢。是否可以实现高性能的Java分析器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！