3 ms·
Someone correct me if I'm wrong but this looks like another failed attempt at profiling Java code. This approach forces a safepoint and therefore all results w
by bitcharmer 4y ago
Someone correct me if I'm wrong but this looks like another failed attempt at profiling Java code.
This approach forces a safepoint and therefore all results will be safepoint biased. That's a very good way to mislead oneself about where the cpu time goes.
The correct way is to employ asynchronous stack probing like async profiler or any other modern profiler does.
- parttimenerd 4y ago(Author here) I want to quote from my article: "Writing a Java profiler in 240 lines of pure Java is possible and the resulting profiler could even be used to analyze performance problems. This profiler is not designed to replace real profilers like async-profiler, but it demystifies the inner workings of simple profilers." And you'll find a large disclaimer on top of the article explaining the safepoint-bias and linking to relevant blog posts by other people on this topic. Please don't use this profiler in production, but you use it to further your knowledge of profilers. > The correct way is to employ asynchronous stack probing like async profiler or any other modern profiler does. Guess what my other articles on my blog are about :) But as you'll see, using the asynchronous APIs is far harder and requires knowledge on POSIX signals, C programming and more that many Java developers do not have.
- bitcharmer 4y agoThanks for the clarification, I skimmed through the content faster than I should have. I stand corrected : - )