Pass args to process.nextTick()

[trevnorris]

Now allow process.nextTick(callback[, ... vargs])

R=@bnoordhuis

[cjihrig]

Any chance of figuring this out before merging?

[trevnorris]

I will. Just don't have the brain cells at the moment to figure out why process.nextTick() returns undefined in the mentioned test.

[mscdex]

I just tested this and all tests (including test-repl-timeout-throw) still pass after changing this additional instance of process.nextTick() to process.nextTick(afterWrite, stream, state, finished, cb);

[trevnorris]

Thanks. I'll make the change to the PR.

[rvagg]

this is a tiny bit gross and a quite a leaky abstraction, I'm not really a fan of exposing ugly APIs just because it's the fastest way--fine if it's an internal API for the sake of cleaning up and speeding up (does it really do either of those?) but now we have to expose this to users.

process.nextTick(cb[, arg1[, arg2... ] ]) would be the obvious API choice because of the consistency and my vote would be that if we can't do that without taking a performance hit then we shouldn't do anything.

[trevnorris]

@rvagg leaky? and it does both clean up and speed up (removing the need for additional function closures, flatten function declarations and no need to create an actual array). I played with the other API decision, but it causes far too many DEOPTs in nextTick() to be useful. And I disagree we shouldn't do anything. Internals are a CF of function declarations that prevent further optimizations.

[rvagg]

leaky abstraction in the sense that your abstraction is saying too much about the implementation -- you're declaring to the world that you had to make compromises on your API to get other outcomes (performance), there has to be a tradeoff between pure perf and the best internal implementation and the API we expose to users and I'm here representing the API and this is that tradeoff discussion

[piscisaureus]

I agree with @rvagg. This adds API that may seem nice and fast now but we have to support it forever. It would be more helpful if the setArgs api was strictly internal.

[cjihrig]

@piscisaureus as in _setArgs()?

[tellnes]

I also agree with @rvagg on this. If we do need an ugly API, then let us try to find a way to not expose it.

[vkurchatkin]

+1 on making this internal. See discussion in #953

[medikoo]

This is quite dirty design, totally not common to similar API's, that people are familiar with.
-1 on having this public, whatever on internal.

[trevnorris]

@medikoo I don't appreciate "dirty design". Yes it's uncommon, but in terms of code complexity and performance it's the cleanest.

setArgs() is now _setArgs().

[vkurchatkin]

setArgs() is now _setArgs().

sigh one more "private" thing that people will use

[trevnorris]

@vkurchatkin I figured the fact that using process.nextTick() is already frowned upon, and the fact that this API isn't documented was enough. Guess a simple _ gives people a feeling of security.

[rvagg]

sigh one more "private" thing that people will use

I echo your sigh here, could we make use of Symbol here maybe or should we just get that internal modules thing sorted out?

[trevnorris]

@rvagg unless we're willing to either 1) remove process.nextTick() completely, or 2) have two implementations of nexTick() (one internal, the other user facing) neither of those solutions will work.

[vkurchatkin]

should we just get that internal modules thing sorted out

we can have this without internal modules

@trevnorris I'm thinking about 2: user facing one would be just a wrapper of internal one

[chrisdickinson]

This may prove problematic for porting it to readable-stream, since it's using an API that browserify (almost certainly) does not support.

[chrisdickinson]

If we end up going this route, I'm in favor of going the internal module + private symbol approach for solving this so we don't expose the setArg API to the world. I really don't want a "internal only" nextTick API.

(This is also a fairly precarious change for readable-stream, no matter which way the flow of code goes. Either way, it may not have access to .setArg.)

[vkurchatkin]

@chrisdickinson I propose injecting private nextTick into internal modules with this new functionality. No symbols are required

[chrisdickinson]

@vkurchatkin Then we have two nextTick's, one private and one public. I'd rather just make this one sub-method private.

[vkurchatkin]

@chrisdickinson What I mean is something like this: process.nextTick = function(cb) { nextTick(cb); }. The same function, just return undefined

[sam-github]

@trevnorris can you comment on why this API is faster than

process.nextTick(fn, [ctx])

?

I assume it was because you don't want to slice fn off the start of arguments before applying the remaing args to fn, but if you limit to one arg, you don't have to.

[chrisdickinson]

@vkurchatkin How does that private nextTick get shared with _stream_readable.js?

[vkurchatkin]

it is passed as an argument to module wrapper. Not a good idea for _stream_readable.js though as it is supposed to be the same as in readable-stream, so only public APIs.

[sam-github]

Oh, and if nextTick is worth making better for use in iojs, its worth making it better for everybody, IMHO.

[trevnorris]

@sam-github It makes the call to nextTick() polymorphic. And only allowing a single argument isn't enough in many cases. So it could possibly make the call megamorphic. Thus preventing nextTick() from being inlined.

[trevnorris]

I won't accept nextTick(callback[, ... vargs]) because of how it'll affect performance. And readable-stream only uses public API. So either we expose this or nothing goes in.

[chrisdickinson]

Just thinking through this out loud, with regards to readable streams: even with an exposed setArg API, wouldn't this preclude us from importing these changes into the streams3 readable-stream branch?

[sam-github]

@trevnorris thanks, I get it. It is unfortunately ugly... but that might limit its use to just performance-critical code... which would be OK.

Is megamorphic even a word? :-)

[petkaantonov]

This could be also merged right now as an unobservable change (with the doc changes reverted) and make the public API "release" later in a semver-minor.

[trevnorris]

Thanks @petkaantonov. That would be my preference.

[Fishrock123]

@trevnorris done any benchmarks yet?

I see that was the resolution as of the tc-meeting it was discussed in.

[trevnorris]

@Fishrock123 some. Initial results showed improvements just above the margin of error. Part of the gain also comes from easier performance debugging, since functions won't DEOPT from being scoped. It's possible to create a benchmark that shows significant gains, but this is definitely a micro optimization.

[trevnorris]

@iojs/tc Was this supposed to have landed before the 1.7 release?

[cjihrig]

LGTM. Starting CI to verify.

[cjihrig]

CI: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/515/

[trevnorris]

Thanks. Landed in 10e31ba.

[jbergstroem]

Possibly stupid question, but seeing this is server-minor - is 1.8.0 our next release?

[rvagg]

@jbergstroem yes, either that or 2.0.0 if we get the https://github.com/iojs/io.js/milestones/2.0.0 changes sorted out

[trevnorris]

@jbergstroem this should have been merged before 1.7 but wasn't.

[jbergstroem]

Ok. I was pretty keen on getting 1.7.2 within a week or so with a fix to a shared build. Guessing 2.0 might make that easier since we'd branch off to master/1.x/2.x?

[19h]

🎉 🎉 Awesome! 🎉 🎉

[igl]

Since nobody mentioned it: Isn't callback.bind(ctx, ...args) the same thing? Even more extensive with the possibility of setting a context.

[petkaantonov]

@igl Yes, well only that, it's like 100000x slower.