Google Material Theme builder demo seems to spend time in Baseline
Categories
(Core :: JavaScript Engine: JIT, enhancement)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
()
Details
go to https://material-foundation.github.io/material-theme-builder/#/dynamic
On the bottom left, there are multiple "wallpapers" that you can choose
Click on each wallpaper one-by-one
ER: The preview on the right pane gets updated quickly
AR: Very slight delay
https://share.firefox.dev/3LKNb91
The profile suggests that some JS code is spending time in Baseline. Maybe something to make faster here?
|
Reporter | |
Updated•3 years ago
|
|
||
Comment 1•3 years ago
|
||
I do not see a lag in loading these wallpapers and also do not see a disproportionate amount of time spent in JS, so I'm not sure there is much to do in this case.
|
|
Reporter | |
Comment 2•1 year ago
•
|
||
Profiles from latest Nightly and Chrome:
Nightly: https://share.firefox.dev/3IPQxaB / https://share.firefox.dev/3Ivuwxr
Chrome: https://share.firefox.dev/49RsALW
@iain: is there anything worth improving here? Nightly's second profile suggests that in the intiial couple of button presses, lots of time is spent in baseline compiling adn there is a lot of mutex overhead? After 10 or so button clicks, the time in Baseline appears to decrease.
|
||
Comment 3•1 year ago
|
||
Nothing immediately leaps out at me here.
It looks like this is Dart code transpiled to JS. I believe that Dart is moving to target Wasm now that there's GC support, so this kind of code may be less important in the future.
I don't see a huge difference between Chrome and Firefox here. It's possible that Chrome is a little faster than us here, but not enough to make me think something's obviously wrong.
I don't see the mutex overhead. Unless you mean ZwWaitForAlertByThreadId? That's just idle time; it's all under mozilla::TaskController::GetRunnableForMTTask, which is the event loop waiting for an event.
We could reopen this and shove it in the backlog, but I think the odds of this ever bubbling up to the top of our priority queue are low enough that it's probably not worth it.
|
|
Reporter | |
Comment 4•1 year ago
|
||
Cool, thanks for the explanation!
(In reply to Iain Ireland [:iain] from comment #3)
I don't see the mutex overhead. Unless you mean
ZwWaitForAlertByThreadId? That's just idle time; it's all under mozilla::TaskController::GetRunnableForMTTask, which is the event loop waiting for an event.
There was a profile I captured that had a non-JS function called mutex as a top function, but I cant repro it now. But in any case, it doesnt matter :)
Description
•