Skip to content
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

[Feature suggestion] Converter for Trace Event json (Chrome as viewer) #447

Closed
benaadams opened this issue Aug 24, 2019 · 11 comments · Fixed by #894
Closed

[Feature suggestion] Converter for Trace Event json (Chrome as viewer) #447

benaadams opened this issue Aug 24, 2019 · 11 comments · Fixed by #894
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@benaadams
Copy link
Member

benaadams commented Aug 24, 2019

@rickbrew mentioned on twitter he'd added tracing to Paint.NET using the tracing format used by Chrome (and Brave and the new Microsoft Edge) dev tools.

It would be good to add this as and output/conversion format for dotnet-trace as either browsers UI are highly developed and well used and understood especially by webdevs and it can happily open and analyse file in that format from other sources.

Trace Event spec

chrome://tracing can open gzipped files (.json.gz) where as dev tools only understands them as raw .json. Dev tools is a little easier to use (and probably most familiar) whereas tracing is a dedicated UI for looking at larger traces. So it may be useful to provide an additional .gz output option, but not have it as the default.

The json is also a format speedscope understands

/cc @migueldeicaza @lucasmeijer

@jorive jorive added the enhancement New feature or request label Aug 26, 2019
@josalem
Copy link
Contributor

josalem commented Aug 26, 2019

I just took a look at the file format, and it seems remarkably similar to the speedscope format (or I guess speedscope seems similar to it 😛). If I find some time, I'll take a look at what what amount of work it would take to write a converter.

@josalem
Copy link
Contributor

josalem commented Aug 27, 2019

Sneak preview:
image

Needs a little polish, but it went together pretty quickly. Won't open in edge://tracing, but opens in devTools (haven't tried Chrome yet). Very cool timeline view of stacked icicle graphs per thread!

@benaadams
Copy link
Member Author

Wow that was fast! 😄

@josalem
Copy link
Contributor

josalem commented Aug 27, 2019

I was intrigued by the idea 😄! Current version is hacked together building off @adamsitnik's work for the speedscope format. I need to figure out where this code will live after I polish it. I did a similar converter that lit up cachegrind using the callgrind.* format, which will hopefully make it in as well.

@adamsitnik
Copy link
Member

@josalem awesome! Can't wait to use it!

I need to figure out where this code will live after I polish it

perhaps it could live in TraceEvent as the SpeedSopeExporter?

@jmezach
Copy link

jmezach commented Sep 7, 2019

@josalem Did you manage to find a place for the code? I'm doing a talk on the new diagnostics tooling soon and opening up the trace in Chrome/Edge Developer Tools would make for a pretty awesome demo IMHO ;).

@tommcdon tommcdon added this to the 5.0 milestone Sep 12, 2019
@josalem
Copy link
Contributor

josalem commented Sep 12, 2019

@jmezach, I haven't had a chance to polish it yet. I will most likely be putting it next to the SpeedScopeExporter in TraceEvent over in Microsoft/PerfView. I'll hopefully get a chance in the next couple weeks to polish it. Give me a sec and I'll push my hacked version of dotnet-trace that you can use to either convert a current trace or collect a new one. It is a hack, so it has errors in the data and whatnot, but will generate that fun view in Edge/Chrome. Note that the file size for this format blows up. I'll hopefully fix that 😅.

@adamsitnik
Copy link
Member

@josalem any progress on this? I am demoing dotnet diagnostics tools at a conference next week and I would love to show it too ;)

@josalem josalem self-assigned this Nov 4, 2019
@josalem
Copy link
Contributor

josalem commented Nov 6, 2019

@adamsitnik here's a link to my hack branch: https://github.com/josalem/diagnostics/blob/bd21c0d4efd2d2ea1c5b361fdfa015034cfd74ce/src/Tools/dotnet-trace/TraceFileFormatConverter.cs#L102-L520.

I'm intending to take some time to polish this, but I'm not sure when that will be. The few outstanding issues with it seem to be

  • bad time information
    • relative time seems fine, but total time seems off Took a quick look and this is coming from the fact that TraceEventJson format takes timestamps in μs while TraceEvent gives us data in ms. Easy to fix.
  • huge file size
    • I made no attempt to condense information or look at mechanisms in the file format to do so. I'm not sure what kind of size improvements can be made.

I'll probably put this code in Microsoft/PerfView, but I had it in dotnet/diagnostics for hacking

@adamsitnik
Copy link
Member

huge file size

I just wanted to let you know that last week I've meet Martin Cervinka, the author of https://gitlab.com/virtex/tracing who said that this problem can be solved by zipping the trace file and that Chrome is capable of opening zipped trace files.

@martincervinka
Copy link

@adamsitnik thank you for introducing me to dotnet-trace and point me here.
@josalem

  • TraceEvent gives us data in ms.

I know it's a bit general question. but I'm very surprised that dotnet-trace TraceEvent has a timestamp resolution only in milliseconds. Is it true?

@ghost ghost locked as resolved and limited conversation to collaborators Jun 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
7 participants