- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 Jul 2018 01:45:29 +0000
- To: public-houdini-archive@w3.org
The Working Group just discussed `Generator vs. Promise design for the API`, and agreed to the following: * `RESOLVED: use Promises` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Generator vs. Promise design for the API<br> <fantasai> github:<br> <fantasai> github: https://github.com/w3c/css-houdini-drafts/issues/750<br> <fantasai> iank_: Did some benchmarking<br> <fantasai> iank_: The Promise solution is slightly slower, but not that much slower<br> <fantasai> iank_: That makes me lean towards Promises solution<br> <fantasai> iank_: Advantage of gnerator is that it's faster, don't have to kick the ? every time<br> <fantasai> iank_: there's some overhead for doing that<br> <fantasai> iank_: However, I think that's acceptable from an author expectation perspective<br> <fantasai> iank_: If it was 30-40% overhead, that might be a concern<br> <fantasai> iank_: but turned out to be not as much of a problem<br> <fantasai> Rossen: What did you test?<br> <fantasai> iank_: Test was 100 custom layout elements<br> <fantasai> iank_: went about 6 layers deep, and had two child nodes at each level and 4 leaf nodes<br> <fantasai> iank_: tree structure, roughly 100 nodes<br> <fantasai> iank_: used our perf testing framework<br> <fantasai> iank_: I did a synchronous version of the API, didn't have any generators, promises, etc. Just exectued synchornously<br> <fantasai> iank_: That was about 650 runs per second<br> <fantasai> iank_: Our current impl was about 430 runs per second<br> <fantasai> iank_: so 50% off the synchronous one<br> <fantasai> iank_: Promises was 450 runs per second<br> <fantasai> iank_: Might be able to get it faster, push around 500 or something<br> <fantasai> iank_: We do lose a lot of perf by allowing async here<br> <fantasai> iank_: so something else to consider<br> <fantasai> iank_: One thing we could revisit later is, asnchornous layout engines<br> <fantasai> iank_: we could potentially get perfr by exposing synchronous versions of layout APIs<br> <fantasai> iank_: so leave that door open<br> <fantasai> iank_: I'll need to do some work, spec wise, to get it so that an impl can run this synchronously<br> <fantasai> iank_: Still requres a queue to go thorugh layout requests<br> <fantasai> iank_: Once I've got that written down, make sure it makes sense to everyone<br> <fantasai> frremy: What if you await Promise that never returns?<br> <fantasai> iank_: IWhen you call layoutNextFragment(), pushes a request onto an internal queue. If layout engine has exhausted that queue<br> <fantasai> iank_: It'll keep queuing its own tasks, flush that queue and echeck if resolved prmise is done<br> <fantasai> iank_: If ....<br> <fantasai> iank_: Summary of the engine is, layoutnextfragment), pushes onton internal queue for custom layotu instance. Layout engine will enqueue a microtask.<br> <fantasai> iank_: lay everything out and then queue tiself again in case extra work<br> <fantasai> iank_: if it finishes, then... if promis is resolved, then done<br> <fantasai> Rossen: So, resolution is to switch back to Promises<br> <fantasai> Rossen: Any additional comments or objections?<br> <fantasai> eae: Can we add a note about err-handlign expectations?<br> <fantasai> ACTION: iank to add note about error-handling expectations<br> <trackbot> Error finding 'iank'. You can review and register nicknames at <https://www.w3.org/Style/CSS/Tracker/users>.<br> <fantasai> RESOLVED: use Promises<br> <fantasai> (and add note)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/750#issuecomment-401650301 using your GitHub account
Received on Monday, 2 July 2018 01:45:41 UTC