Re: [css-houdini-drafts] [css-layout-api] Generator vs. Promise design for the API

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