-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
waterfall performance #40
Comments
The line referred to is https://github.com/caolan/async/blob/master/lib/async.js#L494 . Is scriby's thought about callstack depth the reasoning here? Also, has anyone compared the performance of nextTick for immediate? |
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its alizbazar@gmail.com ------- This is a copy of the message, including all the headers. ------ ----==_mimepart_5335ae2a6a4ed_7cc23f992bedf2c01193d5 Closed #40. Reply to this email directly or view it on GitHub: Closed #40. — ----==_mimepart_5335ae2a6a4ed_7cc23f992bedf2c01193d5-- |
I did some performance testing and noticed that waterfall has quite a bit more overhead than series (about 5x). I would guess it's because it uses nextTick between each step in the waterfall.
Is nextTick there to prevent the call stack from growing out of control? I think you can call the next step directly, but keep track of how many calls have been made in the waterfall, and once it reaches are certain point (around 50?), dispatch the next call using nextTick. That should reduce the overhead associated with nextTick and still prevent the call stack from growing out of control.
The text was updated successfully, but these errors were encountered: