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 <i...@izs.me> 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 <i...@izs.me> 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 <i...@izs.me> 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.
>
>
>
