Diagnostics: [Proposal] Introduce a new tool for converting traces

[adamsitnik]

From the user perspective, I would like to:

• be able to convert .trace.zip files captured with perfcollect to speedscope|chromium format to avoid the need of using a Windows machine while investigating .NET Core performance on Linux (cc @tmds @roji @AndyAyersMS)
• specify fold patterns. A good use case is folding CPU_TIME and UNMANAGED_CODE_TIME for dotnet trace captured traces (cc @swift-kim)
• specify time range to limit the size of the output file (very useful when working with chromium trace files which are VERY big, 15s of TechEmpower benchmark run on 28 core machine = 2 GB JSON file..)

The natural (and easy) choice to me would be to extend the dotnet trace convert command with new parameters. But in #905 @noahfalk mentioned that he would prefer to avoid adding new features to dotnet trace that depend on TraceEvent library (to be able to remove this heavy dependency in the future) so extending dotnet trace convert command is not an option.

So we need a new global tool for converting and filtering trace files. Since the tool will basically expose some of the PerfView features I wonder:

• where it should belong: https://github.com/dotnet/diagnostics or in https://github.com/Microsoft/perfview ?
• what would be a good name for it? (I am very open to any suggestions)

@noahfalk @brianrob what do you think?

[noahfalk]

Adding @hoyosjs

where it should belong: https://github.com/dotnet/diagnostics or in https://github.com/Microsoft/perfview ?

My opinion would primarily be based on engineering efficiency in two areas, effort to make a PR and effort to release a build. For making a PR I expect perfview repo is easier because TraceEvent and perfcollect are already there and those are the most likely pieces of code you would change at the same time you updated the converter. For effort releasing a build the diagnostics team has been making a lot of effort in the past getting set up to publish global tools. I am hoping @hoyosjs can comment on whether that effort could quickly and easily be duplicated in the PerfView repo. If it is easy to replicate I'd recommend hosting the tool in the Perfview repo, otherwise I'd suggest the diagnostics repo.

what would be a good name for it? (I am very open to any suggestions)

Brainstorming:
dotnet-traceconverter, dotnet-ctf convert, dotnet-lttng convert?
Another option might be calling it dotnet-perfcollect and treat it as a helper where you can put any functionality that is easier written in C# than bash?

[noahfalk]

I noticed that @tdms mentioned in #905 the prospect of having dotnet-trace subsume perfcollect entirely. I don't recall if we discussed that in the past but if that sounds appealing as an alternative I am open to exploring it with you @adamsitnik. As mentioned in the comment over there I have concerns about what it would do to the CLI complexity of dotnet-trace but my fear may turn out to be unfounded.

[hoyosjs]

Looking at the perfview repo, it looks like they don't use Arcade as an engineering solution. However, their solutions are a lot more "Vainilla SDK solutions" and they've solved their own infrastructure: how to sign and package and publish - I couldn't look at the details because I couldn't find where the pipeline lives. If the tool remains largely managed, this could be fairly easy. It would just be setting these properties in the csproj: <PackAsTool>true</PackAsTool>, list the rids in PackAsToolShimRuntimeIdentifiers, and give it a name in ToolCommandName. The versioning strategy they use is a bit more manual, so there's updating a number per release. Given that both repos use SDK style projects, if the tool remains largely managed then moving them between repos is also fairly straightforward.

[brianrob]

@hoyosjs, you're right, PerfView does not use Arcade. But we do support signing and all of the stuff that you need to do to release using the standard tools.

@adamsitnik I share your desire to have more fully functional analysis on Linux. I think a tool that does this would be great. I just replied to #905 to try and understand a bit more about the desire to merge perfcollect and dotnet-trace. As I said there, I see these two as different tech, but I'm open to being convinced that they should live together. If they are in-fact different tech, I'm definitely open to having a tool that runs on Linux. PerfView already has a tool called PerfViewCollect (I know... more names that all sound the same) that is designed to be a non-GUI version of PerfView. It was originally designed to run on Nanoserver, but represents a basis for a cross-platform (.NET Core-based) tool that is based on TraceEvent. I would be open to turning this into a .NET global tool, renaming as appropriate, and shipping it to be a TraceEvent-based analysis/converter tool. As an example, PerfViewCollect can already produce and emit GCStats and JitStats on Linux. You could imagine us doing more in this space, and producing formats that are nicely consumable on Linux. We could also take things further and bootstrap this via perfcollect (or completely subsume perfcollect into a cross-platform non-GUI perfview that this tool becomes).

I'm happy to discuss further, have meetings, etc. to dig into this.

[adamsitnik]

I would be open to turning this into a .NET global tool, renaming as appropriate, and shipping it to be a TraceEvent-based analysis/converter tool

I really like this idea!

have meetings

I am going to ping you on Teams and schedule a meeting and after the meeting, share the notes here (so we can get some feedback from users)