-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run the benchmarks #16
Comments
I'm working on it, I will make PR to add Yaku to the benchmark list later. |
Thanks, please keep me updated. |
@benjamingr The benchmark of bluebird is strange:
It's faster than the raw callback, it's impossible! I suspect the benchmark is not properly designed, I can't trust it before I find an explain. |
That makes sense, allocating a promise is cheaper than allocating a closure. You're very welcome to read the tests yourself and see. For example: doOne(function(err, data){ if(err) return cb(err);
doTwo(data, function(err, data2){ if(err) return cb(err);
doThree(data2, function(err, data3){ if(err) return cb(err);
cb(null, data3.foo);
});
});
}); Vs - What is possible is that the callbacks code can be sped up. Some work went into that by some people - but by all means - a PR would be appreciated. |
Of cause the closure of callback should be pre-allocated and cached, or it's not fair. I don't like the code of the benchmark, it's obscure and not clear for people to reason about what it really does. |
@benjamingr I haven't done much optimization, but yaku is pretty good for now:
|
Ping @spion |
@benjamingr You can run it yourself, I forked bluebird: https://github.com/ysmood/bluebird/commit/826d2262c4b9c746a1fdb362819b0a444b9612d2 |
@benjamingr yes? |
Well, the benchmarks were being criticized, thought you might want to address that
|
Ah. To be honest I've never seen callbacks run slower than (generatorless) promises in that benchmark. Sounds like V8 might've decided to bail out on optimising some function on that particular run for some reason. Regarding the way the benchmark is written, it could indeed use some refactoring. Regarding the way the callback code is written, thats only the baseline in bluebird's fork - there are many more variants in the original |
@benjamingr I did some optimization, now Yaku is much better.
|
This is getting there! 1/2 the speed and 1/3 the memory usage of bluebird is very nice :) I still think there is room to go though. Definitely better than what core-js currently uses - if the API is compatible I'm for it :) |
@winterland1989 Very sorry for that, I meant to credit you when I finished all the optimization include the This trick is used by
But I don't think we should mention things like that everyday, because Like I told you the |
OK, thanks for explanations, and i'd like keep communicate with you on |
@winterland1989 Looking forward your breaking through on the |
One thing to be noted that, this trick which try to cover some cases when arguments is less than given point cause way too much memory allocation, you can measure it by print system memory usage before |
Hey, can you run @spion's benchmarks that simulate a real server async workload and report the results?
Here it is: https://github.com/petkaantonov/bluebird/tree/master/benchmark
Cheers.
The text was updated successfully, but these errors were encountered: