Providing more information about stack trace element, like line (if present) and jar file name will help faster to find and eliminate the issue. Line information will help to search faster, without looking for entire classes when finding needed method. There are plugins, which contains some classes of other plugins to replace. In that case we may go into a trap, finding issue in wrong place.

Another useful information would be counting calls to that point of stack trace. Because we make a summ of time, it would be better to see, how many times that line called in order to measure average impact of each call. Aikar's timings provide that info, but they do not provide full stack trees as spark do.

I just replied in Discord re: counting calls.

Luck Today at 19:50
re count feature, you can kinda determine that already
it will never be accurate though, because the data is formed through sampling, and therefore by definition is an average
"average count" can be determined by dividing the total time of the node by the sampling interval
i'm reluctant to include that as it's own property on the viewer because a) I don't want to overload the page with data and b) because it wouldn't be accurate
it wouldn't be accurate because the value would actually represent how many samples the sampler happened to capture whilst that stack was running - not the number of times the actual method had been called

re: jar file name - I'm not sure how useful it'd be?

re: line numbers, I've tried before (see #1) - the info you get from it isn't really useful, and it divides the data up, making it significantly harder to read/interpret.

re: jar file name - I'm not sure how useful it'd be?

When one plugin has overriding classes of another. For example WE and FAWE before 1.13

re: line numbers, I've tried before (see #1) - the info you get from it isn't really useful, and it divides the data up, making it significantly harder to read/interpret.

Make that optionally on web side? (checkbox or something)
And in case it really needed, we can toggle it.

Does it also separate it based on where it's called from? So if the same method calls one method in multiple places it'd show which call uses how much time

Yep, that's the idea. :)

When one plugin has overriding classes of another. For example WE and FAWE before 1.13

In the context of performance profiling, I don't see how knowing this is useful. Aaand even if knowing it was useful, WE & FAWE is quite a niche example. I really want to avoid cluttering the UI with more info.

Make that optionally on web side?

Unfortunately this isn't possible - the node stacks are generated by the profiler, not the web viewer.
Only way around this is to generate two call stacks and send them both to the web client, but this isn't really an acceptable solution as a) it makes the sampling process slower and b) takes up double the storage space.

Unfortunately this isn't possible - the node stacks are generated by the profiler, not the web viewer.
Only way around this is to generate two call stacks and send them both to the web client, but this isn't really an acceptable solution as a) it makes the sampling process slower and b) takes up double the storage space.

But we can send node stacks with lines included, and on web side decide based on some trigger (checkbox) - show them or not, right?

Hovering over the line number in the web viewer explains what it means.

The number displayed next to each element in the output is actually the line number corresponding to where that method was invoked in the parent method. This isn't the same as in stack traces - but it makes the most sense when viewing the full call tree in this way.