Closed
Bug 748512
Opened 13 years ago
Closed 10 years ago
Investigate slowness when switching scripts while debugging
Categories
(DevTools :: Debugger, defect, P3)
DevTools
Debugger
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: rcampbell, Unassigned)
References
Details
Start the Debugger on a page with a lot of scripts. There may be some startup slowness populating the list of scripts.
Reporter | ||
Comment 1•13 years ago
|
||
Good example case is twitter.com. Switching scripts with the list is quite slow.
Summary: Investigate startup slowness when debugging → Investigate slowness when switching scripts while debugging
Updated•13 years ago
|
Assignee: nobody → vporof
Updated•13 years ago
|
Priority: -- → P2
Updated•13 years ago
|
Status: NEW → ASSIGNED
Comment 2•13 years ago
|
||
I herd some orion updates will autofix this.
Assignee: vporof → nobody
Status: ASSIGNED → NEW
Reporter | ||
Comment 3•12 years ago
|
||
from playing with this in the SPS profiler, the following stand out:
_modifyContent > _updatePage > _createLine 20.9% > _createSpan 9.9%
… _getLineBoundingClientRect 12.1% >DoReflow 11%
_modifyContent and updatePage seem to be pretty heavy hitters, consuming a high percentage of time. They reduce to _createLine and _createSpan being the big culprits in there. I think some targetted profiling around these methods would help.
_getLineBoundingClientRect is another big contender causing reflows with every invocation.
Comment 4•12 years ago
|
||
(In reply to Rob Campbell [:rc] (:robcee) from comment #3)
> from playing with this in the SPS profiler, the following stand out:
>
> _modifyContent > _updatePage > _createLine 20.9% > _createSpan 9.9%
>
> … _getLineBoundingClientRect 12.1% >DoReflow 11%
>
>
> _modifyContent and updatePage seem to be pretty heavy hitters, consuming a
> high percentage of time. They reduce to _createLine and _createSpan being
> the big culprits in there. I think some targetted profiling around these
> methods would help.
>
> _getLineBoundingClientRect is another big contender causing reflows with
> every invocation.
Awesome profiling is awesome. I guess these are all methods implemented in the orion engine. Maybe showing these results to the orion people would help them?
Comment 5•12 years ago
|
||
(In reply to Victor Porof [:vp] from comment #4)
> Awesome profiling is awesome. I guess these are all methods implemented in
> the orion engine. Maybe showing these results to the orion people would help
> them?
Indeed. I'm already on it - contacted them. Upstream is aware of the issues, but we haven't come yet to a solution to avoid the numerous calls to "reflow triggers".
Thanks Rob for profiling!
Updated•12 years ago
|
Priority: P2 → P3
Comment 6•12 years ago
|
||
Let's check on this again after Orion is updated.
Comment 8•10 years ago
|
||
Nobody is working on this, but I haven't heard any complains after our switch to CodeMirror.
Flags: needinfo?(vporof)
Comment 9•10 years ago
|
||
(In reply to Victor Porof [:vporof][:vp] from comment #8)
> Nobody is working on this, but I haven't heard any complains after our
> switch to CodeMirror.
Should be safe to close this bug then. We can always reopen when it becomes a problem again in the future.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•