Closed Bug 1161693 Opened 5 years ago Closed 3 years ago

Nothing should block responsiveness in performance tool.

Categories

(DevTools :: Performance Tools (Profiler/Timeline), defect, P2)

37 Branch
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jsantell, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [polish-backlog][difficulty=hard])

There are a few scenarios which result in blocking on the perf tool client. Some scenarios:

* Importing a profile (150mb profile takes 1s to fetch, 1.2s to convert from stream to string, and 1.5s to JSON.parse)
* Rendering Call Tree and Flame Graph causes huge blocking. CallTrees can take up to 10s to render on my machine for an octane profile.
* RecordingUtils -- these may introduce some blocking, but I've never seen these, even in heavy situations, take longer than 10ms on a large amount of data.

These processes should be investigated to see if maybe a worker would benefit from this.
This is a meta bug for this, so can pull these out into their own bugs.
Blocks: perf-perf
Whiteboard: [devedition-40]
Worker utils landed in bug 1126457, and while did not provide a speed increase for RecordingUtils, may improve responsiveness.
For call trees, I suspect making sure that only the visible nodes are rendered at a time would improve things drastically.

FlameGraphs should render very fast, but it's the initial data source massaging to build the visualization that's causing some lag. Or are you talking about actual responsiveness while scrolling?
FlameGraph rendering is pretty fast, and you're right, it's getting data in that format that takes a bit.
Priority: -- → P2
Whiteboard: [devedition-40] → [polish-backlog]
Whiteboard: [polish-backlog] → [polish-backlog][difficulty=hard]
This bug is no longer valid as we're moving forward with Bug 1408124
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.