Your intention is to break up a computationally intensive task, does that latency to run the units really matter under load?
Benchmarks alone are not helpful unless you do them in the context of a real use case. Yes, latency is an issue, but the latency you're talking about would be less than the computation time, otherwise you wouldn't have bothered to break it up. Adding latency to the units of computation actually ensures the operations won't take over the process, which is the entire point of breaking it up. As a matter of fact, if the latency isn't more than the computation time then it's not much use. Maybe at this point we can all see why this is a bad way to handle computationally expensive tasks. We need to stop this insane fascination with benchmarks around non-use cases. Not trying to have a go at you Bruno, this just happens to be the 10th one of these I've seen in as many days and now I want to burn the internet. Everyone is doing this and I don't believe it helpful any longer. -Mikeal On May 29, 2012, at May 29, 20121:54 PM, Bruno Jouhier wrote: > 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. >
