It would be nice to filter async-profiler's output when profiling JMH runs to include only traces from the benchmarked methods, excluding e. g. @Setup and @Teardown.
async-profiler produces output in a simple text format that you can easily filter with grep etc.
I think recently integrated async-profiler and JMH (with flamegraphs).
Details:
This is, IMO, a bad idea for any benchmark involving multiple threads.You are essentially saying you are not interested in any profile data from:聽
If your cpu cycles are spent in your benchmark thread, great, you got the profile you want anyhow, with some marginal data. If this is not the result you already got, why are you trying to ignore all this data about where the cycles are actually spent?
Also, grep.
My integration does gather samples from all threads, but only starts
profiling after the warm up iterations conclude.
@nitsanw in my case @Setup contains some very heavy stuff, in fact heavier than the execution itself, and it contaminates the profile. It doesn't make the analysis impossible, but harder.
You can say the same thing about JMH's -gc option - why would you not include GC in benchmarking, it's a part of a real application. But sometimes this option is useful.
@apangin yes, it could probably be something as simple as after-the-fact filtering (although I think not as primitive as grep). I just think it's worth to maintain such utility in the async-profiler repository.
Why grep is not enough? What else do you expect from the feature?
@leventov OK, reading the conversation more closely I think I understand your requirement, still not sure async-profiler is the place for it, but lets see.
I believe what you are looking for is a jmh-profiler integration for async-profiler:
I think I misunderstood what you meant by including only the benchmark methods, I believe what you meant is include only the measurement period, which is the standard way JMH profilers work. That makes sense?
From my recollections of looking at profiler integration for JMH this is very doable, but it's not clear to me that such a project needs to be part of the async-profiler repo. It would make sense IMO to have it in it's own repo, and require users to include it in their "project to be profiled" and expect them to install async-profiler separately. This is consistent with the perf profiler experience(except that it is internal and therefore requires no extra dep).
Makes sense?
I'm going to contribute an async-profiler integration to JMH. Here's my work so far: https://github.com/retronym/jmh/pull/2
JMH 1.24 includes -prof async.
Most helpful comment
JMH 1.24 includes
-prof async.