Open brianrob opened 1 year ago
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:
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.
cc: @birojnayak, @smhmhmd
To make it cross platform, migrate from WPF to Avalonia UI. Someone wrote an guide
To make it cross platform, migrate from WPF to Avalonia UI. Someone wrote an guide
Absolutely a reasonable option to consider.
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.
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.