Performance timeline being a heavy tool defeats its own purpose

I have a project that has performance issues, so naturally I'd like to be able to debug it, check which parts of the reactivity are the worst offenders.

But guess what - the very tool that is supposed to help with the issue has a warning that it has a big performance impact.
So when I start recording with the timeline, I can't unclick it anymore as it gets clogged due to the amount of events.

If the only performance debugging tool the devtools have is itself not-resiliant to working under heavy load then it defeats its own purpose. Because by the very definition, it is most needed when the application has performance problems.

The tool itself may be taxing on the resources, but it has to be resilient while working under heave load.
Now, I don't know the internal architecture of the extension, but things that come to my mind are that:

• Make it so that it's always possible to finish recording events, regardless of the load. Perhaps it would be possible to split some of the work into a separate thread so that the plugin is responsive while recording.
• Maybe I don't need to see events real-time. It is okay to collect them as raw data (preferably as lightweight as possible, non-reactive, damn maybe even as a JS Buffer if it will be more lightweight than objects) and post-process it into objects and make it browse-able after recording.
• If the above will be still clogging the user, just let me download the data. Even as a JSON file.

The issue names no files, tests, or entry points, so first map the timeline recording path and its event collection and rendering components. Review how recording behaves under heavy load and define completion as a responsive stop action with usable recorded data or an exportable JSON result.