Building a Cross-Platform PerfView

[brianrob]

There has been some renewed interest in building a cross-platform version of PerfView. Historically, PerfViewJS was an attempt at this, however, it had one big issue that ultimately caused us to archive the repo. Whenever a new feature was added to PerfView, it did not automatically get added to PerfViewJS. This is because PerfViewJS isn't PerfView - It is a TraceEvent-based viewer with a web-based front-end. While valuable, there wasn't sufficient interest in adding features to PerfViewJS after they were added to PerfView.

Going forward, if we're going to bring PerfView to non-Windows platforms, I want us to do the work directly in PerfView so that any improvements to PerfView automatically accrue to all platforms. I think that at a minimum, a cross-platform PerfView should support Windows, Linux, and OSX. In this issue, I'll describe the steps that I know of that will be required to do this. Not all of the steps are clear yet, and so we'll need to dig into those as we get closer. But in the meantime, if folks are interested in helping to bring PerfView to non-Windows platforms, let's do it.

Extremely Rough High-Level Plan

Beta Give feedback

1. Port PerfView to run on .NET 7 (or 8) on Windows.
2. Implement non-UI-based functionality for Linux and/or EventPipe-based traces (e.g. GC/JIT stats).
3. Investigate cross-platform UI frameworks.
4. Implement PerfView's UI in a new cross-platform framework.

I acknowledge that there are lots of tasks built into this plan that aren't listed here. For example, just porting to .NET Core likely means re-designing how PerfView is packaged - right now it is a single-file that unpacks itself. This won't be possible on .NET Core, so we likely will need to investigate options. One option would be to look at what's possible with .NET Core single-file deployments. Another would be to build a native wrapper and have it extract PerfView and the runtime and run it.

Let's use this issue as a jumping off point to discuss options and to track this work.

[brianrob]

I think the first step here should be to start with PerfViewCollect and see if you can expand it to handle more and more PerfView code. Right now, it's just a command line collector that runs on .NET Core, so perhaps the first two steps there are:

1. Move PerfViewCollect to .NET 7 (it's currently running on .NET Core 3.1)
2. Try to make the UI run on .NET Core. Note that we don't necessarily want to get rid of PerfViewCollect, as we still use it in containers that don't have UI libraries installed on them (e.g. nanoserver), but this is a good way to expand outwards from a starting point.

Where I'd like us to end up is that we have two builds of PerfView side-by-side - one that runs on .NET Framework and one that runs on .NET Core. This allows us to do this work in relative isolation.

[brianrob]

cc: @birojnayak, @smhmhmd

[MagicAndre1981]

To make it cross platform, migrate from WPF to Avalonia UI. Someone wrote an guide

[brianrob]

To make it cross platform, migrate from WPF to Avalonia UI. Someone wrote an guide

Absolutely a reasonable option to consider.