Gather and publish CSS Typed OM performance data in an explainer? · Issue #634 ·...
source link: https://github.com/w3c/css-houdini-drafts/issues/634
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
I've done some initial benchmarking. tl;dr Allocating Typed OM objects is slow, so you have to reuse objects for performance gains.
The first benchmark just calls StylePropertyMap.set with a precomputed Typed OM object. This shows that skipping CSS parsing indeed brings performance gains [1], as long as we reuse objects. In the benchmark, you can play around with iterations to change the amount of reuse per cycle.
The second benchmark tests a common use case: getting a value from the style map, modifying it, and then putting it back. Here, strings is slightly faster. I suspect this is because we create a new object every time we call StylePropertyMap.get. Perhaps we can optimise for this case with StylePropertyMap.update (reuse the same object over multiple calls?). Also, the benchmark shows a simple case of parsing a length. If we had to parse complicated objects like transforms in JavaScript (I don't actually know to do this properly), I suspect Typed OM would be faster.
[1] On my Chrome Canary (66) build, I get:
string x 18,769 ops/sec ±1.21% (94 runs sampled)
typed x 21,627 ops/sec ±1.86% (88 runs sampled)
Fastest is typed
[2] I got:
string x 513,838 ops/sec ±1.11% (95 runs sampled)
typed x 480,403 ops/sec ±5.46% (79 runs sampled)
Fastest is string,typed
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK