This is an attempt at getting a promise library to run as fast as native callbacks while still offering Promises/A+ compatability. It was sparked by these tweets:
We would not give up perf in core. You can already do this in userland if you have diff priorities.
It would take some work to optimise and you couldn’t use something like Q, but I’d be surprised if it couldn’t be done.
node promises will have to be as fast as "Base" (current callbacks) in this benchmark
It's intended as a proof of concept, The .then
method isn't quite good enough to pass the Promises/A+ test suite and crucially it doesn't have any way of handling non-truthy errors. I also haven't spent any time testing it, but it is principally possible to create a then
method that is compliant except for the flasy errors issue on top of this implimentaiton.
Note that I've not actually used the .then
method, instead I've created a much more optimised .nodeify
method. Anyone who uses promises seriously as promises will of course get the slight performance drop of using a real .then
method (probably a perf drop of about 30% - 40%). The point I wanted to make though is that you can make the .then
method available while still providing a high performance alternative for those who don't have complex control flow problems to manage.
@ForbseyLindsay that way is not possible to get 1:1, as we always end up writing a wrapper over original callback.
It has to be done by hacking Node internals. Let's not handle callback but return promise from original
lstat
, then see if we can makelstat(path).done(cb)
as fast as originallstat(path, cb)
.I believe it will require some work in C++ layer, and even if we get 1:1 in this benchmark, it's good to check whether in general, creation of thousands of promise objects (instead of just passing values to callback) doesn't introduce any perf problem (memory consumption ?)