YourKit CPU Call Tree Filtering

[telemenar]

I've only comparatively recently switch to profiling Java code after a long time using other profiling tools.

One What-If style feature I really miss from Apple's Instruments is: Charge <> to Callers

This removes the <> symbol from the call tree then, any callees (frames down the call tree) of that symbol are treated as having been directly called by any callers (frames up the call tree) of that symbol and any self time/samples are added to the self time/samples for the callers (frames up the call tree) of that symbol. (They also support doing this on a library level as well.)

Is there any way to do something like this in Yourkit?

While the filter and prune options can sometimes get me partway there, they don't give me quite the same result.

Prune just removes the whole subtree, or all subtrees with the target symbol, whereas "charge" leaves callees intact.
Filter because it leaves a boundary frame doesn't always let me manipulate the call tree to highlight what "charge" allows.
Method Merged Callees comes the closest. Though it decontextualizes more.

If this feature is there I'd love some guidance on how to use it. If it is not there, it would be awesome if this could be added to some future roadmap.

[Vladimir Kondratyev]

Please take a look at https://www.yourkit.com/docs/java-profi ... ilters.jsp

Filters do exactly what you're requesting.

Best regards,
Vladimir Kondratyev
YourKit GmbH
http://www.yourkit.com
"Don't get lost in data, get information!"

[telemenar]

It doesn't appear to work like I'd want out of the box. Though now that I've played a little with it I think I can make it work.

The example that I have is that I'd really like to filter/remove/charge to callers, the various different methods from `SmartOp` in this snippet of a flame graph, basically the different entry points is not relevant to what I'm currently investigating instead I just want to blend the call stacks of all children:


If I just add `SmartOp` to a filter it doesn't seem to do anything:


Applying that results in no change to the tree. I made sure that filters were applied by disabling and enabling all filters, and the class path I copied from the stack trace.

The workaround that I just found is that if I also add `StraightPipe` to the filter then I get the result that I want and in this case `StraightPipe` isn't that important.
Filter change:

Flame graph change:


So not sure if this is a "as intended" or not?
It would also be nice if there was a "Filter Method" option in the CPU menu, so that you don't have to take as many steps to construct these filters?