Lots of jank in the profiler on latest nightly.
Categories
(Core :: Gecko Profiler, defect, P2)
Tracking
()
People
(Reporter: emilio, Unassigned)
References
Details
See profile here: https://share.firefox.dev/3THincu
This was while seeing https://share.firefox.dev/3sbFZKe and / or https://share.firefox.dev/3THnuJl
|
Reporter | |
Comment 1•2 years ago
|
||
Doesn't seem like a recent regression. Those (old-ish) profiles spend a lot of time on canvas2d code, both in the content and rendered threads.
|
|
Reporter | |
Comment 2•2 years ago
|
||
It's also really slow in Chrome too... Maybe something for the profiler folks to look at?
|
||
Comment 3•2 years ago
|
||
We'll have to look closely, but my rough guess is that the cause is that we have a lot of DOMEvent markers (among others), and those are drawn in the timeline. I believe that we didn't do the same perf improvements for markers in the Timeline than what we did in the Marker chart, and we could try to fix that.
|
||
Updated•2 years ago
|
|
||
Comment 4•2 years ago
|
||
I'm surprised that set CanvasRenderingContext2D.fillStyle is 25% of the time: https://share.firefox.dev/3soOmCB (and most of it is in Servo_ComputeColor doing malloc and free calls). Emilio, is there room for optimization there?
|
|
Reporter | |
Comment 5•2 years ago
|
||
Do you know what the fillStyle argument is? The parser allocates in some cases but mostly when given keywords:
(I'd expect inlined functions in there but seems they're not there? Is there a way to get them to track down where the allocation comes from exactly?)
|
|
||
Comment 6•2 years ago
•
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
Do you know what the fillStyle argument is? The parser allocates in some cases but mostly when given keywords:
To answer the question, I added AUTO_PROFILER_MARKER_TEXT("SetStyleFromString", DOM, {}, aStr); in CanvasRenderingContext2D::SetStyleFromString. Here's the profile I got:
https://share.firefox.dev/3zd6brN
From the console, I executed: copy(filteredMarkers.map(m=>m.data.name).join("\n"))
I pasted the result in a fillString.txt file, and then:
% sort fillString.txt|uniq -c|sort
1 hsla(0,0%,100%,0.3)
6 #9400ff
8 #0a84ff
116 #00feff
1106 hsla(0,0%,0%,0.05)
3563252 black
(I'd expect inlined functions in there but seems they're not there? Is there a way to get them to track down where the allocation comes from exactly?)
My profile contains inlined frames: https://share.firefox.dev/3SEK8kW
|
||
Comment 7•2 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
(I'd expect inlined functions in there but seems they're not there? Is there a way to get them to track down where the allocation comes from exactly?)
We've been having some trouble with the symbol server recently where the symbolication request fails (probably because the server runs out of memory, bug 1793984), and then we fall back to local symbols from the binary. In that case, re-symbolicating the profile can sometimes help.
|
|
Reporter | |
Comment 8•2 years ago
|
||
3563252 black
Yeah, so as suspected, black is an identifier and allocates because we usually need to preserve the identifier for serialization purposes. Though in this case we don't I guess, so that's something we could optimize.
|
|
||
Comment 9•2 years ago
|
||
If changing to an RGB value helps here, that should be an easy change.
|
||
Comment 10•2 years ago
|
||
The severity field is not set for this bug.
:canova, could you have a look please?
For more information, please visit auto_nag documentation.
I've created a PR to change these blacks to rgb values, hoping that it will increase the performance a bit: https://github.com/firefox-devtools/profiler/pull/4319
Do you think there are other things that we can improve?
|
|
Reporter | |
Comment 12•2 years ago
|
||
That was fixed already in bug 1798932 fwiw.
Description
•