Though process.nextTick() *itself* is fast, delaying calling the callback until it gets through that queue can have large performance implications, for example, in our case, we may have a tick of our physics simulation queued up (which could take hundreds of ms), and if some logic has to go through a few process.nextTicks, all interspersed with some other expensive operations in between, this kind of API can lend itself to some poorly performing side effects.
That being said, I do agree that it's generally "best practice" to do this, but it's good to be aware that it's not always the best for performance (in some of our own APIs, where we set them up to always call the callbacks asynchronously, we have needed to add short-cuts in a couple of cases where it had a significant impact on latency). On Thursday, October 11, 2012 1:36:58 PM UTC-7, Adam Crabtree wrote: > > It's a best practice because it helps those unfamiliar with the reasoning > to keep from shooting themselves or their users in the foot. There are > several ways that this may affect you, but a quick summary can be found > here: > > http://howtonode.org/understanding-process-next-tick > > How slow is process.nextTick? A quick benchmark reveals it's not just > <1ms, but in fact is roughly 1µs (0.001ms for the lazy): > > var i = 0, sum = 0 > ;(function foo() { > var t = process.hrtime() > process.nextTick(function() { > sum += process.hrtime(t)[1] > if(++i<10000000) return foo() > console.log('Average time: ', sum/i) > }) > })() > > That being said, there are always exceptions to the rule, and if you > understand the tradeoffs and have a need to shave off µs, then go for it. > Chances are though, for the other 99.9% it's a micro-optimization (no pun > intended ;P). Again, this requires a special set of circumstances to be an > issue, but when it is, discovering that the cause was a cache hit and a > synchronous call to callback can be frustrating. > > Cheers, > Adam Crabtree > > On Thu, Oct 11, 2012 at 12:50 PM, Axel Kittenberger > <[email protected]<javascript:> > > wrote: > >> > I'd rather see client patterns that are immune to callbacks being >> called before the function returns sometimes. >> >> Ditto! >> >> We should encourage people to write callers that are good, rather than >> libraries that deliberately waste performance and tell the callers >> "its alright you wrote bad code, they have to put in a >> process.nextTick anyway". And < 1ms can be a lot in some areas. >> >> Document your function accordingly, if it guarantees a particular >> callback/return order or not. In many situations, standard is, >> callback immediately if you have all what is needed for the callback. >> If the caller fucks up, that one should be fixed, instead of the >> callee. >> >> Or in other words, cure the problem, not the symptom. >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> > > > > -- > Better a little with righteousness > than much gain with injustice. > Proverbs 16:8 > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
