Firefox takes 2.3x time as Chrome computing style on Editor-CodeMirror
Categories
(Core :: CSS Parsing and Computation, enhancement)
Tracking
()
People
(Reporter: jlink, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [sp3])
Attachments
(1 obsolete file)
1764 vs 763 samples (diff: 1001, 2.31x): Firefox profile + Firefox profile + Firefox profile vs Chrome profile + Chrome profile + Chrome profile + Chrome profile
Making Firefox as fast as Chrome on this function would reduce its time by 4.5%.
|
||
Updated•1 year ago
|
|
||
Comment 1•1 year ago
|
||
|
||
Comment 2•1 year ago
|
||
FWIW ni?ing would be more effective. I think given that profile all the problems stem from dynamically adding this contenteditable.css stylesheet:
That makes us first spend a bunch of time in CascadeData-related stuff, then also match a lot more elements that we'd otherwise do.
Here's a patch that should verify that... https://treeherder.mozilla.org/jobs?repo=try&revision=f0027b11a69d03f47ad0f83e428d82551075bb15
Can you run a comparison with that patch? Nowadays the contenteditable sheet is quite useless IMHO. Mostly for legacy editor features.
I sent it to try anyways.
|
|
||
Comment 3•1 year ago
|
||
Can we remove the image resizing / inline table editing? I could probably rewrite them to be faster but I'd rather not?
|
|
||
Comment 4•1 year ago
|
||
Move the relevant bits to html.css or other UA sheets, and use faster
things than attribute selectors for resizers and such things.
|
|
||
Comment 5•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
Can you run a comparison with that patch? Nowadays the contenteditable sheet is quite useless IMHO. Mostly for legacy editor features.
Chrome: 791 samples
Current Nightly: 1902 samples
This try build: 1498 samples
So that try build improves our time on the subtest by 1.6%, whereas closing the full gap to Chrome would improve our time on the subtest by 4.6%.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
Can we remove the image resizing / inline table editing? I could probably rewrite them to be faster but I'd rather not?
I think it's no at least immediately because they are used in Thunderbird, and IIRC, the former was intentionally used even in Firefox when we checked the usage with telemetry. (Of course, it surprises us.)
However, they are disabled by default even though document.execCommand can enable each. So, I wonder, some paths still run within the benchmarks??
Ah, about the style for the Gecko specific editing UIs?
If they could be loaded dynamically when they are required at first time, we could load them around here.
|
||
Comment 8•1 year ago
|
||
Comment on attachment 9461314 [details]
WIP: Bug 1911140 - Remove contenteditable / EditorOverride sheet.
Revision D235319 was moved to bug 1943542. Setting attachment 9461314 [details] to obsolete.
Description
•