-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibly use a known profiling format for timings ? #43804
Comments
With respect to @matthewhammer's |
That would still have the same spilllover problems. A real profiler would show that type-checking uses the time for type-checking + everything is forced. Similarly, |
What I mean is that a profiler collect way more information that can be processed in various ways afterwards with something like flame graphs or perf-focus. This allows get the cost of a some function, even if it is called on demand.
I see two options here:
Option (2) seems more future-proof to me, although option (1) is more platform independent. |
Getting a flame graph of queries out of a normal profiler run on a rustc with debuginfo-lines is pretty easy. |
Yes, I know. That's way I'm not sure if we should put effort into maintaining |
It's useful for getting a quick review of how things are going, especially on "customer machines". |
I agree, it's useful for that. |
It's been a few years; did anything come out of the discussion? Is this bug useful? |
This bug doesn't seem to be useful so I'm going to close - we're discussing profiling elsewhere as part of the self profile working group. |
And we plan to support a format that both https://perf-html.io/ and the Chromium tools support. |
With the new
-Z trans-time-graph
from #43506, soon to be joined by-Z profile-queries
from #43345, and their impact ontime-passes
, would it make sense to output such timings in an existing profiling format instead of ad-hoc ones ?A couple formats come to mind:
They both seem to support multiple processes/threads, and the frontend tools are pretty powerful in filtering, sorting, etc.
Chrome's format looks easy to generate, and Aras P had a couple good articles about how they use it at Unity:
Gecko's and perf-html looks more complex/complete and has a seriously impressive polished UI (but might have some Firefox related concepts, ie JS or C++ contexts one can see in the UI). To see how it looks, here's an example of a big trace from gecko+stylo (I think, I saw this in the servo irc chan)
I think both frontends could be used on perf.rlo. I know Chrome's trace viewer can be compiled to a single (huge) html file one can use outside of Chrome to trace json timing files. And I think perf-html is client-side only as well.
(As an aside, could it also be interesting to output to such formats with a more fine-grained profiling data successor to
time-passes
— and not just for the 2 HTML outputs mentioned above ? I think this would be extremely useful to see and track hotspots on perf.rlo, which IIRC will probably switch to only showing totals without passes data)cc @michaelwoerister, @eddyb, @nikomatsakis
The text was updated successfully, but these errors were encountered: