Investigate current source of slowness in Speedometer BackboneJS subtest
Categories
(Core :: Performance, task)
Tracking
()
Performance Impact | none |
People
(Reporter: tcampbell, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [sp3-anyone])
The BackboneJS subtest of both Speedometer2 and Speedometer3 currently is about half the speed of Chrome. It has the worst slowdown of any of the subtests and due to the geomean calculation of score this may be an opportunity to improve scores easier than other cases. BackboneJS performance probably has less user impact than React performance, but closing the gap would improve speedometer2 score 4-5%.
This benchmark appears to be extremely skewed by the Firefox Profiler, so this probably needs some extra care to study. It is also a short benchmark so only a few samples are recorded.
- Try profilers other than Firefox Profiler
- Manually instrument benchmark code
- Change iteration code
- Explore disabling different JITs or features and try to identify the levers that affect performance
- ???
There does seem to be a fair amount of JIT compile activity which when profiled causes a lot of script tracking and jitspew code to get involved which completely skews the profile.
Comment 1•2 years ago
|
||
Nazim, could you take a look at the profiler overhead also in this case?
It looks like capturing the stacks of markers are the biggest issue. Bug 1814908 is adding a new feature to the about:profiling page that disables the marker stack capturing.
Here's an example profile with the patches in that bug applied: https://share.firefox.dev/3xcCyW9
It looks like the overhead is reduces significantly. There is only one sample with the profiler category left and that seems to be during the marker serialization.
Also Olli mentioned in matrix that "In backbone.js DeletingAllItems overhead goes from 14% to ~0." which is great!
I will do some more profiling with that feature and see if I can catch some stuff we can optimize. But other than this one, I think the biggest issue left is the lock contention while adding markers.
Updated•2 years ago
|
Comment 3•2 years ago
|
||
One thing I've noticed when playing with mozjemalloc is that BackboneJS-Todo likes large page cache more than other JS heavy Todos.
Updated•2 years ago
|
Description
•