- From: Darren Shen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Feb 2018 01:08:51 +0000
- To: public-houdini-archive@w3.org
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](http://jsfiddle.net/tbgj5ybu/) 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](http://jsfiddle.net/pa7nfg3a/) 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](https://drafts.css-houdini.org/css-typed-om-1/#dom-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 ``` -- GitHub Notification of comment by darrnshn Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/634#issuecomment-362956713 using your GitHub account
Received on Monday, 5 February 2018 01:09:18 UTC