3 ms·

This seems a lot more complicated than something like this: if (!(value instanceof Promise)) { value = Promise.resolve(value) } And then you w

by c-baby 4y ago

This seems a lot more complicated than something like this: if (!(value instanceof Promise)) { value = Promise.resolve(value) } And then you write the rest of your code as if it is async.

tobr 4y ago
Not as if. You’re making a synchronous call async. And so it keeps spreading through your code. Op’s trick is certainly more complicated but looks like a smart way to support async cases but still letting synchronous calls stay synchronous.
- c-baby 4y ago
  Hmm I see. So the value is in creating a kind of blocking promise. I can see how that might be useful in certain circumstances, but using blocking functionality isn't something you'd want to rely on in general.
  - qazxcvbnm 4y ago
    No, the promise doesn't block, it just stays a promise. However, for synchronous calls, the Promise overhead is obviated. In other words, the performance price of synchronous vs asynchronous calls is the price of a function call vs Promise implementation (i.e. event-loop machinery); the price of a function call, including the stack frame allocation, which is non-zero (recall the times that assembly programmers would dismiss languages like C as 'too-slow', having to allocate on function calls), versus pushing the Promise closure onto an event-loop, exiting the current event-loop, waiting for the next event-tick, popping off the next closure from the event stack, then creating the function call stack frame under a closure. For inner-loops, the difference can be 20ms vs 20s.
- pmoleri 4y ago
  I don't get it, the signature still returns `Type | Promise<Type>` how that promise doesn't spread through your code? Still, the other comment about using await on plain values seems like a better option than parent comment
  - tobr 4y ago
    c-baby’s suggestion wraps a non-promise in a promise, so I don’t see how that’s still able to return a non-promise. Awaiting plain values can only be done inside an async function, which means it returns a promise, which means you have to wait for the event loop to get the value out of there. Generally I’m not aware of any other (reasonably ergonomic) way to write a single code path that can work with both sync and async input without itself always giving async output.
jitl 4y ago
It's very easy to make sync code async. Just add an `async` to the function declaration. You don't need the `instanceof` check or `Promise.resolve` - you can `await` any type of value; it'll get unwrapped as a Promise if it has a `then` method, or otherwise just give you back the value. See [MDN for await]. If that's okay for your code, then go for it. However, downgrading a sync function to be async has serious performance implications - turning a trivial sync function call in a tight loop into an awaited async function call will make your loop 90%+ slower [benchmark]. You're also going to allocate much more memory for Promise objects. The code I linked above is from a library implementing a sandboxed Javascript VM. If we forced all calls into the guest sandbox, or from the guest sandbox back to host functions like `console.log`, to be async, the VM would be unusable for many applications. [MDN for await]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#return_value https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [benchmark]: https://jsbench.me/y0la7auape/2 https://jsbench.me/y0la7auape/2
- deleted 4y ago
  [deleted]
- c-baby 4y ago
  I see what you’re saying. For your bench mark code, it doesn’t look like you’re using a generator? How does the await compare to a generator? I only ask because the non-async example looks like there are a million ways the runtime could optimize it that might not apply in practice. (I’m on my phone now, otherwise I would try it).
  - qazxcvbnm 4y ago
    OP's technique is useful for a consumer of a another function, to consume it in a synchronity-agnostic manner. In the implementation of the function consumer, you should find the usage of OP's technique. In other words, this technique allows a library's implementation and interface to be synchronity-agnostic, but it does not say anything about the library user. If the library user likewise makes use of the OP technique, the library user code will remain synchronity-agnostic, otherwise it will be tied to be either synchronous or be asynchronous (parametrised to the synchronity).

by c-baby 4y ago

This seems a lot more complicated than something like this: if (!(value instanceof Promise)) { value = Promise.resolve(value) } And then you write the rest of your code as if it is async.

tobr 4y ago

Not as if. You’re making a synchronous call async. And so it keeps spreading through your code. Op’s trick is certainly more complicated but looks like a smart way to support async cases but still letting synchronous calls stay synchronous.

c-baby 4y ago
Hmm I see. So the value is in creating a kind of blocking promise. I can see how that might be useful in certain circumstances, but using blocking functionality isn't something you'd want to rely on in general.
- qazxcvbnm 4y ago
  No, the promise doesn't block, it just stays a promise. However, for synchronous calls, the Promise overhead is obviated. In other words, the performance price of synchronous vs asynchronous calls is the price of a function call vs Promise implementation (i.e. event-loop machinery); the price of a function call, including the stack frame allocation, which is non-zero (recall the times that assembly programmers would dismiss languages like C as 'too-slow', having to allocate on function calls), versus pushing the Promise closure onto an event-loop, exiting the current event-loop, waiting for the next event-tick, popping off the next closure from the event stack, then creating the function call stack frame under a closure. For inner-loops, the difference can be 20ms vs 20s.
pmoleri 4y ago
I don't get it, the signature still returns `Type | Promise<Type>` how that promise doesn't spread through your code? Still, the other comment about using await on plain values seems like a better option than parent comment
- tobr 4y ago
  c-baby’s suggestion wraps a non-promise in a promise, so I don’t see how that’s still able to return a non-promise. Awaiting plain values can only be done inside an async function, which means it returns a promise, which means you have to wait for the event loop to get the value out of there. Generally I’m not aware of any other (reasonably ergonomic) way to write a single code path that can work with both sync and async input without itself always giving async output.

jitl 4y ago

It's very easy to make sync code async. Just add an `async` to the function declaration. You don't need the `instanceof` check or `Promise.resolve` - you can `await` any type of value; it'll get unwrapped as a Promise if it has a `then` method, or otherwise just give you back the value. See [MDN for await]. If that's okay for your code, then go for it. However, downgrading a sync function to be async has serious performance implications - turning a trivial sync function call in a tight loop into an awaited async function call will make your loop 90%+ slower [benchmark]. You're also going to allocate much more memory for Promise objects. The code I linked above is from a library implementing a sandboxed Javascript VM. If we forced all calls into the guest sandbox, or from the guest sandbox back to host functions like `console.log`, to be async, the VM would be unusable for many applications. [MDN for await]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#return_value https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [benchmark]: https://jsbench.me/y0la7auape/2 https://jsbench.me/y0la7auape/2

deleted 4y ago
[deleted]
c-baby 4y ago
I see what you’re saying. For your bench mark code, it doesn’t look like you’re using a generator? How does the await compare to a generator? I only ask because the non-async example looks like there are a million ways the runtime could optimize it that might not apply in practice. (I’m on my phone now, otherwise I would try it).
- qazxcvbnm 4y ago
  OP's technique is useful for a consumer of a another function, to consume it in a synchronity-agnostic manner. In the implementation of the function consumer, you should find the usage of OP's technique. In other words, this technique allows a library's implementation and interface to be synchronity-agnostic, but it does not say anything about the library user. If the library user likewise makes use of the OP technique, the library user code will remain synchronity-agnostic, otherwise it will be tied to be either synchronous or be asynchronous (parametrised to the synchronity).