[dotnet trace] Add Chromium Trace Event file format to list of supported formats

[adamsitnik]

This is a continuation of microsoft/perfview#1113

The only thing I was not sure was whether we should compress the file by default or not. There are two ways of opening the trace file in chromium browsers and only one supports compressed files:

• by using chrome://tracing or edge://tracing/ - it supports compressed files

• by using DevTools (F12 in chromium based formats) - it does not support compressed files and IMHO has better visualization capabilities than tracing view

I am open to suggestions and changing it to always compress the file. Or perhaps in the future we should add an extra argument to the convert command that would control the compression?

The CI is going to be red until a new version (2.0.50) of TraceEvent is pushed to nuget.org which should happen soon (@brianrob has already bumped the version numbers in perfview repo microsoft/perfview@2c8fd78)
I have tested it locally against a local build of TraceEvent.

Fixes #447

/cc @josalem @tmds @noahfalk

[brianrob]

I just release TraceEvent 2.0.50. It is now available on GitHub and should be available on NuGet within the hour: https://www.nuget.org/packages/Microsoft.Diagnostics.Tracing.TraceEvent/2.0.50.

[adamsitnik]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 894 in repo dotnet/diagnostics

[adamsitnik]

Without this change I was getting following error:

PS C:\Projects\diagnostics\src\Tools\dotnet-trace> dotnet run -c Release convert --format chromium
Writing:        C:\Projects\diagnostics\src\Tools\dotnet-trace\trace.chromium.json
System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.Diagnostics.Tracing.TraceEventRawReaders.ReadInt32(IntPtr pointer, Int32 offset)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.<>c__DisplayClass82_0.<SetupCallbacks>b__36(GCMarkWithTypeTraceData data)
   at Microsoft.Diagnostics.Tracing.TraceEventDispatcher.DoDispatch(TraceEvent anEvent)
   at Microsoft.Diagnostics.Tracing.EventPipeEventSource.DispatchEventRecord(EVENT_RECORD* eventRecord)
   at Microsoft.Diagnostics.Tracing.EventPipeEventSource.EventCache_OnEvent(EventPipeEventHeader& header)
   at Microsoft.Diagnostics.Tracing.EventPipe.EventCache.SortAndDispatch(Int64 stopTimestamp)
   at Microsoft.Diagnostics.Tracing.EventPipe.EventCache.ProcessEventBlock(Byte[] eventBlockData)
   at Microsoft.Diagnostics.Tracing.EventPipeBlock.FromStream(Deserializer deserializer)
   at FastSerialization.Deserializer.ReadObjectDefinition(Tags tag, StreamLabel objectLabel)
   at FastSerialization.Deserializer.ReadObject()
   at Microsoft.Diagnostics.Tracing.EventPipeEventSource.Process()
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.CopyRawEvents(TraceEventDispatcher rawEvents, IStreamWriter writer)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.<>c__DisplayClass118_0.<FastSerialization.IFastSerializable.ToStream>b__0()
   at FastSerialization.DeferedRegion.Write(Serializer serializer, Action toStream)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.FastSerialization.IFastSerializable.ToStream(Serializer serializer)
   at FastSerialization.Serializer.WriteObjectData(IFastSerializable obj, Tags beginTag)
   at FastSerialization.Serializer.WriteObjectRef(IFastSerializable obj, Boolean defered)
   at FastSerialization.Serializer..ctor(IStreamWriter writer, IFastSerializable entryObject)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.CreateFromEventPipeEventSources(TraceEventDispatcher source, String etlxFilePath, TraceLogOptions options)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.CreateFromEventPipeDataFile(String filePath, String etlxFilePath, TraceLogOptions options)
   at Microsoft.Diagnostics.Tools.Trace.TraceFileFormatConverter.Convert(TraceFileFormat format, String fileToConvert, String outputFilename, Boolean continueOnError) in C:\Projects\diagnostics\src\Tools\dotnet-trace\TraceFileFormatConverter.cs:line 68
   at Microsoft.Diagnostics.Tools.Trace.TraceFileFormatConverter.ConvertToFormat(TraceFileFormat format, String fileToConvert, String outputFilename) in C:\Projects\diagnostics\src\Tools\dotnet-trace\TraceFileFormatConverter.cs:line 42

When I include the lastest version of the package in explicit way, the problem is gone.

[sywhang]

Thanks Adam!! Really excited to see this :)

[tmds]

This is awesome! ❤️ 🚀

[brianrob]

@adamsitnik, it looks like you tripped over a bug in the TraceEvent package authoring since version 2.0.50 adds a new dependency on System.Runtime.CompilerServices.Unsafe. The dependency was added but it is not expressed in the nuspec file. I have posted microsoft/perfview#1118 to fix this.

[adamsitnik]

@brianrob nice catch! I assumed that this is some dotnet cli|MSBuild error and just worked around. It's great that you have provided a clean fix.

[josalem]

🚀 Awesome stuff @adamsitnik! @brianrob is it worth waiting for your nuspec update release of TraceEvent to merge this?

[brianrob]

If you can, that would be great. That way we confirm this issue is fixed for everyone. I should have this wrapped up later today.

[brianrob]

I just posted https://www.nuget.org/packages/Microsoft.Diagnostics.Tracing.TraceEvent/2.0.51 which contains the dependency fix. It should be available within the hour and should allow you to revert the extra dependency here.

[adamsitnik]

@josalem I've updated the TraceEvent version, reverted the workaround and tested it locally. Everything works as expected, the PR is ready to be merged ;)

[jnuic7]

It seems like it always shows 17ms as the trace runtime and leaves off most of the user code calls? Are you guys experiencing this at all. To reproduce dotnet trace collect -p 49940 --format chromium, chrome://tracing load. I see the calls show up in the json but not on the viewer

[adamsitnik]

To reproduce dotnet trace collect -p 49940 --format chromium

Hi @jnuic7

49940 is a process runing on your machine so I can't reproduce it. Could you please create a new issue and upload the .nettrace file that dotnet trace produced for you?

[jnuic7]

Hey Adam, apologies was just giving a rough example by giving that process id and appreciate the quick response. Was just checking to see if you guys have run into this issue but I will open an issue

[jnuic7]

Just added an issue #1315. Any help is greatly appreciate and looking forward to being able to use this tool for perf profiling