Tracepoint

[lievenhey]

Show tracepoints in TimeLineWidget

[lievenhey]

[milianw]

there are still no unit tests for any of the new functionality - we need both! i.e. tests for the new behavior of showing tracepoint events in the model, and tests for the favorite.

we also cannot yet undo a favorite action, i.e. remove a favorite

[milianw]

hey @lievenhey - I cleaned up the remaining nits and played around with this. It definitely goes into the right direction.

but there is more work remaining to make this actually useful:

the biggest issue is that all tracepoints for all threads and processes are lumped together into a single row - that is pretty useless.

the way I see it, our "Event Sources" should become a combo box that allows multi-selection. Then, each of these event sources will get one row below the CPU or Thread group.

The proxy should then flatten this, if just a single cost is selected - i.e. such that we keep the view as-is for data files that don't contain any extra tracepoint data.

Right now with your proposed patch here, one can have "Event Source: " and then we'd see the per-thread tracepoints and then one more row with all tracepoints clumped together 🤷 that's not useful

additionally, the tooltips shown in the event delegate are wrong when hovering a tracepoint event, because it only looks at the events of the selected source type, meaning tracepoints are never considered.

once those things are fixed, I am OK with merging this work as a stepping stone. the following steps will then be:

• time measurement between enter/exit similar to off-CPU time
• somehow making sure that the favorite rows are always shown, independent of the vertical current scroll position - potentially through a second view?

[lievenhey]

somehow making sure that the favorite rows are always shown, independent of the vertical current scroll position - potentially through a second view?

using a second view is most likely the easiest option since QWidgets don't have stuff like qmls header or footer

[milianw]

somehow making sure that the favorite rows are always shown, independent of the vertical current scroll position - potentially through a second view?

using a second view is most likely the easiest option since QWidgets don't have stuff like qmls header or footer

Agreed, we just need to sync the views and show just a single header somehow. But this should/ could be done in a follow-up patch and doesn't necessarily block integration of the work here as long as the other important issues are resolved.

[GitMensch]

Is this still in a draft state? It seems that new testcases are now available (but failing) are there still missing ones?

[lievenhey]

@milianw I finally found some time to work in this. Can you check if it to your satisfaction?

[milianw]

are you sure you pushed the correct work? I don't think you attended the issue I raised above, namely:

the biggest issue is that all tracepoints for all threads and processes are lumped together into a single row - that is pretty useless.

I just checked out your branch, rebased it on master and ran it on data I obtained with

perf record -z --call-graph dwarf -e cycles -e raw_syscalls:sys_enter -e raw_syscalls:sys_exit ./tests/test-clients/cpp-parallel/cpp-parallel

The result is still a single list of tracepoints across all threads, which is not useful. What's worse, some threads are suddenly showing up multiple times in the timelines above?

[lievenhey]

Ok, fixed that. Now all events are shown in one line (before there was one line per even type).
That is still somewhat wip since now it is really hard to differentiate different event types since only the tooltip reveals the type. I propose the following:

• different colors for different event types
• when hovering highlight not only all stacks but also all symbols with the same type