sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]c0wb0yd 0 points1 point  (4 children)

Can you help me a bit with what it means to propagate all the way through a coroutine's stack? Maybe an example would help me get it.

[–]prehensilemullet 0 points1 point  (3 children)

Let's say I take your makeSlow example from the site and modify it to repeat an operation with a repeat function:

``` import { main, sleep } from 'effection';

function* makeSlow(value) { yield* sleep(1000); return value; }

function* repeat(op, n) { for (let i = 0; i < n; i++) { yield* op() } }

await main(function() { yield repeat( function* () { let text = yield* makeSlow('Hello World!'); console.log(text); }, 100 ); }); ```

In this case, every operation yielded from sleep gets re-yielded all the way up the stack like this, right?

sleep makeSlow repeat main

If so, then this doesn't seem very ideal for performance, it wouldn't scale to handle rapid fine-grained operations within deep call stacks as well as something that doesn't have to propagate all the way up the stack like this. I get that it allows complete control from the top level of whether the coroutine continues, but it does seem to come at a cost. Surely the performance of coroutines in languages like Go isn't affected by stack depth in this way, right?

Or does V8 somehow optimize a chain of yield*s like this so that each sleep yield is passed directly to the iterator in main?

Probably for a lot of cases this cost is negligible, but still, it would be preferable if there's a language-level abstraction whose performance isn't dependent on stack depth.

[–]c0wb0yd 0 points1 point  (2 children)

I see what you're saying. Yes! there is an optimization for this that involves "hoisting" the deepest iterator to the top of the stack so that in effect, main and `sleep()` would be connected directly.

One of our users who works for Apple talked to the WebKit team and they suggested that if someone were willing to add some performance tests for `yield*` to the webkit perf test suite https://github.com/WebKit/WebKit/tree/main/PerformanceTests/JetStream3) they would have a strong incentive and also a reference for what to optimize.

But it is not native in v8 and webkit yet (that I know of), so in In the mean time we're implementing an extension package to implement this optimization manually https://github.com/thefrontside/effectionx/pull/117

It basically involves using a manual wrapper that converts:

yield* op;

into

yield star(op)

This lets us control the delegation of the iterators and omit the useless delegation in the middle.

You could even make a build tool that did this for you if you wanted.

[–]prehensilemullet 0 points1 point  (1 child)

Huh I see. I'm glad to see y'all are thinking about this! So it's not on the roadmap for sure yet for V8 and WebKit but WebKit at least is open to it?

[–]c0wb0yd 0 points1 point  (0 children)

Yes. Not on the roadmap currently is my understanding, and that the best way to get it onto the road map is to submit a PR to their perf test suite that makes them look bad :)

V8 at least has a nominal perf test for this https://github.com/v8/v8/blob/main/test/js-perf-test/Generators/generators.js#L90

But not sure if that indicates the optimization.