Skip to content

Performance timeline being a heavy tool defeats its own purpose #901

Open
@michaelKurowski

Description

@michaelKurowski

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions