[tentacleuno]

No, the whole point of Promise implementations is not to beat tasks which run in the current event loop tick. That's why you have separate (microtask, macrotask etc.) queues in the first place.

Unnecessarily using Promises introduces further work for the VM, plus it may cause issues with race conditions, wrong variable values (which aren't easy to debug), etc. if you don't hold a magnifying glass to your code.

To be clear, I'm not benchmarking OP's library -- just providing an important note on why you shouldn't use Promise as a general monad. There are libraries for that: maybe not this one, maybe nothing at all. Do whatever works for you :-)

[chmod775]

> No, the whole point of Promise implementations is not to beat tasks which run in the current event loop tick. That's why you have separate (microtask, macrotask etc.) queues in the first place.

We're clearly talking about actual CPU time spent here when comparing code using those approaches. We're not interested in what runs first in some software mixing synchronous and asynchronous code. This is completely irrelevant.

[tentacleuno]

> We're clearly talking about actual CPU time spent here when comparing code using those approaches. This is completely irrelevant.

Perhaps I missed a part of the conversation? I began by highlighting the issues with your approach regarding the event loop, and you started talking about the implementation of this library in particular, seemingly as a counter-argument?

To be clear, I'm not disagreeing that wrapping things is slower than not wrapping them. That's quite obviously true. I'm just pointing out bad advice in your parent comment.