Description
Description
I feel like this panel could benefits from some improvements.
Some of these are actionable right now, but there are some that could be discussed before sending PRs.
For instance:
-
1. The panel currently shows a set of categories hard-coded in the
time.html.twig
template, even if no stopwatch event for these occurred (e.g:propel
). Theevent_listener_loading
one isn't even used since 2.3:
The time collector could provide the list of categories actually used during the request, so the template would only show them. -
2. [HttpKernel] Added support for timings in ArgumentValueResolvers #26833 traces controller argument resolvers since 4.1. But this is not easily identifiable in the panel. We could add a category for it:
- Dedicated category for controller argument resolvers ([HttpKernel][Profiler] Add arg value resolver category in performances panel #28387)
This PR also let me think we could add some other relevant categories. For now, I've in mind two other components for which these kind of metrics would be useful: - Serializer normalizers
- Messenger middleware
👷🚧 Part of this is started in [Messenger][Profiler] Trace middleware execution #27321
- Dedicated category for controller argument resolvers ([HttpKernel][Profiler] Add arg value resolver category in performances panel #28387)
-
3. Disabling some categories by clicking on it would be useful:
-
4. Rendering the graph using a canvas has some drawbacks:
- no interactivity allowed
- no text selection allowed
- we can't use the browser search input to quickly jump to an event
- the graph has a fixed size, which sometimes leads to truncated events (when the event is a long FQCN like the resolvers ones for instance)
Perhaps we could switch to an SVG version to solve these limitations.
Do you think these kind of improvements are worth it? Do you have some others in mind?