4 ms·
The benchmarks in that library are misleading - by wrapping the resolve in the promise example in a process.nextTick you're actually making the engine enqueue
by phpnode 6y ago
The benchmarks in that library are misleading - by wrapping the resolve in the promise example in a process.nextTick you're actually making the engine enqueue 2 microtasks, as promises are always guaranteed to be async. If you remove the process.nextTick the results are reversed, I get:
- 63ms (async)
- 100ms (casync)
so it's almost twice as slow as native async await in this example.
- BenoitEssiambre 6y agoThe main reason for this library has to do with simplification more than performance but just for the sake of argument, in my little benchmark, the point was to make the asynchronous operation identical in both tests. You can use promises without any asynchronous operation inside but what's the point? That's not how they're used most of the time. And sure promises may add a second microtask around the asynchronous code (casync does too in some cases) but that is to their detriment performance wise (and do promises really add a second microtask when the code inside is already asynchronous?). Also note that async has the benefit of language level integration and optimization. It gets to use v8 c++ functions like "EnqueueMicrotask" instead of process.nextTick. If casync had access to all this, it would likely run even faster.