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

Speed scope #114

wants to merge 4 commits into from

Speed scope #114

wants to merge 4 commits into from


Copy link

@adamsitnik adamsitnik commented Jan 19, 2019

@vancem I decided to add the new argument --format to the dotnet-collect tool. IMHO output format of the collect command is more natural to me than new analysis command (we don't analyze anything here). Also the dotnet-collect has the concept of ETW/EventPipe and it was simply very easy to add it there.

If the user specifies --format speedscope I load the trace file and export it to a *.speedsope.json format. The default is just "trace" (does not change existing behavior)

Sample usage:

dotnet run -- --profile Default --format SpeedScope --config-path /Projects/SomeApp/bin/Release/netcoreapp3.0/SomeApp.eventpipeconfig --process-id 792

I added few provider names to the "default" profile. I needed to that to be able to get stack samples and symbols (rundown).

I tested it on macOS and Windows with .NET Core 3.0 and it works.

I am open to any ideas/suggestions/changes.

@adamsitnik adamsitnik requested a review from vancem Jan 19, 2019
var stackSource = new MutableTraceEventStackSource(eventLog);

var computer = new ThreadTimeStackComputer(eventLog, symbolReader);

This comment has been minimized.


sywhang Jan 23, 2019

I believe this line is throwing

EtwCollector.cs(86,36): error CS0618: 'ThreadTimeStackComputer' is obsolete: 'This is not obsolete but experimental, its interface is likely to change' 

in the CI builds :-)

Copy link
Member Author

@adamsitnik adamsitnik commented Mar 27, 2019

@vancem told me that a new tool (dotnet trace) will be created soon and it's going to contain this feature so I am closing this PR

@adamsitnik adamsitnik closed this Mar 27, 2019
Copy link

@josalem josalem commented Apr 12, 2019

@adamsitnik - Would it be possible to incorporate these changes into the updated dotnet-trace tool? If you don't have time, I can take up the effort if you'd be willing to outline the work necessary.

Copy link
Member Author

@adamsitnik adamsitnik commented Apr 16, 2019

Hi @josalem

Unfortunately, I don't have time now but I can outline the work necessary.

The logic that exports the data to a speedscope format lives in SpeedScopeStackSourceWriter.WriteStackViewAsJson which is part of the TraceEvent library (version 2.0.34+).
The method accepts a StackSource which is the provider of all profiling samples for the exporter. You can copy the code from this PR that allows for creating it from the EventPipe file.

Most probably the hardest thing will be choosing the new console argument name ;)

Please let me know if you need any help or something does not work as expected.

josalem added a commit to josalem/diagnostics that referenced this pull request Apr 19, 2019
@josalem josalem mentioned this pull request Apr 19, 2019
josalem added a commit to josalem/diagnostics that referenced this pull request Apr 19, 2019
josalem added a commit that referenced this pull request Apr 19, 2019
* Incorporate code from closed PR #114 to enable speedscope output:
* adds format option

* Actually add the converter...

* update dotnet-trace instructions

* Expanded on output format section of instructions

* Change protection level of TraceFileFormatConverter

* Updates in response to feedback

* Update src/Tools/dotnet-trace/TraceFileFormatConverter.cs

Co-Authored-By: josalem <>

* Update src/Tools/dotnet-trace/CommandLine/Options/CommonOptions.cs

Co-Authored-By: josalem <>

* Fix typos
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants