Just wrote a quick bench: https://gist.github.com/2830638
Results: Benching setTimeout elapsed: 15593 Benching nextTick elapsed: 2226 So, there is a penalty in switching from nextTick to setTimeout: the call is 7 times slower! On Tuesday, May 29, 2012 10:31:41 PM UTC+2, Mikeal Rogers wrote: > > I have never seen nextTick recommended for breaking up computationally > expensive tasks, this is what cluster and child_process are for. > > Also, setTimeout(cb,0) is very efficient in node and does not suffer the > penalties we are familiar with from the browser. It's actually a better fit > for this use case than nextTick(). > > -Mikeal > > On May 29, 2012, at May 29, 201212:23 PM, Bruno Jouhier wrote: > > +1 > > nextTick is the efficient way to yield to another "thread of processing" > (thread between quotes of course) when performing an expensive computation. > So it is the antidote to starvation and thus a very useful call. > > If you change its behavior, you should at least provide a replacement call > which will be at least as efficient (unlike setTimeout(cb, 0)). And then > why not keep nextTick as is and introduce another call with a different > name (like afterTick as someone suggested) if you really need one. > > > On Tuesday, May 29, 2012 2:43:20 AM UTC+2, phidelta wrote: >> >> I think that the current semantics have value. I use nextTick when I >> want to ensure that io can happen between the invocation and the >> ticked call. As well as to work with a new call stack. >> >> For example when I emit an event whose lister also emits an event and >> so on, I create a potentially long chain of stuff that can happen >> within a tick. So when I emit from within a listener I usually >> nextTick the emit to allow io in between. >> >> So if you change nextTick to really mean "at the end of this tick", at >> least we will want a function like reallyNextTick that keeps the >> current behavior. Of course I would need to do a search replace over a >> lot of code, but I could live with that. >> >> >> On May 26, 7:50 pm, Isaac Schlueter <[email protected]> wrote: >> > How would you feel about changing the semantics of process.nextTick >> > such that the nextTick queue is *always* cleared after every v8 >> > invocation, guaranteeing that a nextTick occurs before any IO can >> > happen? >> > >> > This would imply that you can starve the event loop by doing nextTick. >> > So, for example, the timeout would never fire in this code: >> > >> > setTimeout(function () { >> > console.log('timeout')}) >> > >> > process.nextTick(function f () { >> > process.nextTick(f) >> > >> > }) >> > >> > Reasoning: >> > >> > We have some cases in node where we use a nextTick to give the user a >> > chance to add event handlers before taking some action. However, >> > because we do not execute nextTick immediately (since that would >> > starve the event loop) you have very rare situations where IO can >> > happen in that window. >> > >> > Also, the steps that we go through to prevent nextTick starvation, and >> > yet try to always have nextTick be as fast as possible, results in >> > unnecessarily convoluted logic. >> > >> > This isn't going to change for v0.8, but if no one has a use-case >> > where it's known to break, we can try it early in v0.9. > > > On Tuesday, May 29, 2012 10:31:41 PM UTC+2, Mikeal Rogers wrote: > > I have never seen nextTick recommended for breaking up computationally > expensive tasks, this is what cluster and child_process are for. > > Also, setTimeout(cb,0) is very efficient in node and does not suffer the > penalties we are familiar with from the browser. It's actually a better fit > for this use case than nextTick(). > > -Mikeal > > On May 29, 2012, at May 29, 201212:23 PM, Bruno Jouhier wrote: > > +1 > > nextTick is the efficient way to yield to another "thread of processing" > (thread between quotes of course) when performing an expensive computation. > So it is the antidote to starvation and thus a very useful call. > > If you change its behavior, you should at least provide a replacement call > which will be at least as efficient (unlike setTimeout(cb, 0)). And then > why not keep nextTick as is and introduce another call with a different > name (like afterTick as someone suggested) if you really need one. > > > On Tuesday, May 29, 2012 2:43:20 AM UTC+2, phidelta wrote: >> >> I think that the current semantics have value. I use nextTick when I >> want to ensure that io can happen between the invocation and the >> ticked call. As well as to work with a new call stack. >> >> For example when I emit an event whose lister also emits an event and >> so on, I create a potentially long chain of stuff that can happen >> within a tick. So when I emit from within a listener I usually >> nextTick the emit to allow io in between. >> >> So if you change nextTick to really mean "at the end of this tick", at >> least we will want a function like reallyNextTick that keeps the >> current behavior. Of course I would need to do a search replace over a >> lot of code, but I could live with that. >> >> >> On May 26, 7:50 pm, Isaac Schlueter <[email protected]> wrote: >> > How would you feel about changing the semantics of process.nextTick >> > such that the nextTick queue is *always* cleared after every v8 >> > invocation, guaranteeing that a nextTick occurs before any IO can >> > happen? >> > >> > This would imply that you can starve the event loop by doing nextTick. >> > So, for example, the timeout would never fire in this code: >> > >> > setTimeout(function () { >> > console.log('timeout')}) >> > >> > process.nextTick(function f () { >> > process.nextTick(f) >> > >> > }) >> > >> > Reasoning: >> > >> > We have some cases in node where we use a nextTick to give the user a >> > chance to add event handlers before taking some action. However, >> > because we do not execute nextTick immediately (since that would >> > starve the event loop) you have very rare situations where IO can >> > happen in that window. >> > >> > Also, the steps that we go through to prevent nextTick starvation, and >> > yet try to always have nextTick be as fast as possible, results in >> > unnecessarily convoluted logic. >> > >> > This isn't going to change for v0.8, but if no one has a use-case >> > where it's known to break, we can try it early in v0.9. > > > On Tuesday, May 29, 2012 10:31:41 PM UTC+2, Mikeal Rogers wrote: > > I have never seen nextTick recommended for breaking up computationally > expensive tasks, this is what cluster and child_process are for. > > Also, setTimeout(cb,0) is very efficient in node and does not suffer the > penalties we are familiar with from the browser. It's actually a better fit > for this use case than nextTick(). > > -Mikeal > > On May 29, 2012, at May 29, 201212:23 PM, Bruno Jouhier wrote: > > +1 > > nextTick is the efficient way to yield to another "thread of processing" > (thread between quotes of course) when performing an expensive computation. > So it is the antidote to starvation and thus a very useful call. > > If you change its behavior, you should at least provide a replacement call > which will be at least as efficient (unlike setTimeout(cb, 0)). And then > why not keep nextTick as is and introduce another call with a different > name (like afterTick as someone suggested) if you really need one. > > > On Tuesday, May 29, 2012 2:43:20 AM UTC+2, phidelta wrote: >> >> I think that the current semantics have value. I use nextTick when I >> want to ensure that io can happen between the invocation and the >> ticked call. As well as to work with a new call stack. >> >> For example when I emit an event whose lister also emits an event and >> so on, I create a potentially long chain of stuff that can happen >> within a tick. So when I emit from within a listener I usually >> nextTick the emit to allow io in between. >> >> So if you change nextTick to really mean "at the end of this tick", at >> least we will want a function like reallyNextTick that keeps the >> current behavior. Of course I would need to do a search replace over a >> lot of code, but I could live with that. >> >> >> On May 26, 7:50 pm, Isaac Schlueter <[email protected]> wrote: >> > How would you feel about changing the semantics of process.nextTick >> > such that the nextTick queue is *always* cleared after every v8 >> > invocation, guaranteeing that a nextTick occurs before any IO can >> > happen? >> > >> > This would imply that you can starve the event loop by doing nextTick. >> > So, for example, the timeout would never fire in this code: >> > >> > setTimeout(function () { >> > console.log('timeout')}) >> > >> > process.nextTick(function f () { >> > process.nextTick(f) >> > >> > }) >> > >> > Reasoning: >> > >> > We have some cases in node where we use a nextTick to give the user a >> > chance to add event handlers before taking some action. However, >> > because we do not execute nextTick immediately (since that would >> > starve the event loop) you have very rare situations where IO can >> > happen in that window. >> > >> > Also, the steps that we go through to prevent nextTick starvation, and >> > yet try to always have nextTick be as fast as possible, results in >> > unnecessarily convoluted logic. >> > >> > This isn't going to change for v0.8, but if no one has a use-case >> > where it's known to break, we can try it early in v0.9. > > >
