Avoid JS String conversion in strokeStyle / fillStyle setter, for faster lookup of the cached style for a string
Categories
(Core :: DOM: Bindings (WebIDL), enhancement)
Tracking
()
People
(Reporter: mstange, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
(Whiteboard: [sp3])
Attachments
(5 files)
On the Charts-chartjs subtest of Speedometer 3, Firefox currently spends 4x as much time inside the strokeStyle setter as Chrome does.
Firefox: https://share.firefox.dev/4eb551Q (608 samples)
Chrome: https://share.firefox.dev/4e6Grj2 (148 samples, 4x faster)
The strokeStyle setter itself just looks up the string and finds the cached stroke style for it. However, Chrome is much faster at that string lookup.
In Firefox, 40% of the time is spent converting the JS string to an nsCString, and another 40% is spent hashing that string.
Can we do anything to eliminate the string conversion, and maybe even the hashing?
Updated•1 year ago
|
Comment 1•1 year ago
•
|
||
Here's roughly what Chrome does:
// Internalize the string so that we can use pointer comparison for equality
// rather than string comparison.
v8_string = v8_string->InternalizeString(isolate);
if (v8_string->Length()) {
const auto it = color_cache_.Find<ColorCacheHashTranslator>(v8_string);
Comment 2•1 year ago
|
||
Peter, how easy is it for us to get atomized JS strings through our bindings to the C++ code?
Comment 4•1 year ago
|
||
It's not trivial. I'll put up a patch I've been trying out. Sadly it requires JSAPI usage outside of the bindings code, which we try to avoid.
Comment 5•1 year ago
|
||
Comment 6•1 year ago
|
||
Comment 7•1 year ago
|
||
Comment 8•1 year ago
|
||
Comment 9•1 year ago
|
||
Comment 10•1 year ago
|
||
These patches should work. Need to profile first, and then decide whether we want to do this or not.
Description
•