New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass args to process.nextTick() #1077

Closed
wants to merge 1 commit into
base: v1.x
from

Conversation

Projects
None yet
@trevnorris
Contributor

trevnorris commented Mar 5, 2015

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

R=@bnoordhuis

@cjihrig

View changes

Show outdated Hide outdated lib/_stream_writable.js
@rvagg

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Mar 5, 2015

Member

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.

Member

rvagg commented Mar 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 5, 2015

Contributor

@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.

Contributor

trevnorris commented Mar 5, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Mar 5, 2015

Member

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

Member

rvagg commented Mar 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@piscisaureus

piscisaureus Mar 5, 2015

Member

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.

Member

piscisaureus commented Mar 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Mar 5, 2015

Contributor

@piscisaureus as in _setArgs()?

Contributor

cjihrig commented Mar 5, 2015

@piscisaureus as in _setArgs()?

@tellnes

This comment has been minimized.

Show comment
Hide comment
@tellnes

tellnes Mar 6, 2015

Member

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.

Member

tellnes commented Mar 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Mar 6, 2015

Member

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

Member

vkurchatkin commented Mar 6, 2015

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

@medikoo

This comment has been minimized.

Show comment
Hide comment
@medikoo

medikoo Mar 6, 2015

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.

medikoo commented Mar 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 6, 2015

Contributor

@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().

Contributor

trevnorris commented Mar 6, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Mar 6, 2015

Member

setArgs() is now _setArgs().

sigh one more "private" thing that people will use

Member

vkurchatkin commented Mar 6, 2015

setArgs() is now _setArgs().

sigh one more "private" thing that people will use

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 6, 2015

Contributor

@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.

Contributor

trevnorris commented Mar 6, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Mar 6, 2015

Member

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?

Member

rvagg commented Mar 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 6, 2015

Contributor

@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.

Contributor

trevnorris commented Mar 6, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Mar 6, 2015

Member

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

Member

vkurchatkin commented Mar 6, 2015

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

View changes

Show outdated Hide outdated lib/_stream_readable.js
@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Mar 10, 2015

Contributor

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.)

Contributor

chrisdickinson commented Mar 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Mar 10, 2015

Member

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

Member

vkurchatkin commented Mar 10, 2015

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

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Mar 10, 2015

Contributor

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

Contributor

chrisdickinson commented Mar 10, 2015

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

@vkurchatkin

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Mar 10, 2015

Member

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

Member

vkurchatkin commented Mar 10, 2015

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

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Mar 11, 2015

Member

@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.

Member

sam-github commented Mar 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Mar 11, 2015

Contributor

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

Contributor

chrisdickinson commented Mar 11, 2015

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

@vkurchatkin

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Mar 11, 2015

Member

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.

Member

vkurchatkin commented Mar 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Mar 11, 2015

Member

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

Member

sam-github commented Mar 11, 2015

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

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 11, 2015

Contributor

@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.

Contributor

trevnorris commented Mar 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 11, 2015

Contributor

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.

Contributor

trevnorris commented Mar 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Mar 13, 2015

Contributor

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?

Contributor

chrisdickinson commented Mar 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Mar 17, 2015

Member

@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? :-)

Member

sam-github commented Mar 17, 2015

@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? :-)

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 18, 2015

Contributor

@sam-github usage in only performance critical code was my plan, and the fact I've left it undocumented since we want people to use setImmediate(callback[, ... vargs]) anyway should demonstrate it's limited use case for very high performance code. Don't know if megamorphic is in any dictionary, but it is fun to say. :)

Contributor

trevnorris commented Mar 18, 2015

@sam-github usage in only performance critical code was my plan, and the fact I've left it undocumented since we want people to use setImmediate(callback[, ... vargs]) anyway should demonstrate it's limited use case for very high performance code. Don't know if megamorphic is in any dictionary, but it is fun to say. :)

@rvagg rvagg added the tc-agenda label Mar 18, 2015

@petkaantonov

This comment has been minimized.

Show comment
Hide comment
@petkaantonov

petkaantonov Mar 27, 2015

Contributor

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.

Contributor

petkaantonov commented Mar 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 27, 2015

Contributor

Thanks @petkaantonov. That would be my preference.

Contributor

trevnorris commented Mar 27, 2015

Thanks @petkaantonov. That would be my preference.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Apr 8, 2015

Member

@trevnorris done any benchmarks yet?

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

Member

Fishrock123 commented Apr 8, 2015

@trevnorris done any benchmarks yet?

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

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Apr 8, 2015

Contributor

@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.

Contributor

trevnorris commented Apr 8, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Apr 15, 2015

Contributor

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

Contributor

trevnorris commented Apr 15, 2015

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

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Apr 15, 2015

Contributor

LGTM. Starting CI to verify.

Contributor

cjihrig commented Apr 15, 2015

LGTM. Starting CI to verify.

@cjihrig

This comment has been minimized.

Show comment
Hide comment

trevnorris added a commit that referenced this pull request Apr 15, 2015

node: allow multiple arguments passed to nextTick
PR-URL: #1077
Reviewed-by: Colin Ihrig <cjihrig@gmail.com>
@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Apr 15, 2015

Contributor

Thanks. Landed in 10e31ba.

Contributor

trevnorris commented Apr 15, 2015

Thanks. Landed in 10e31ba.

@trevnorris trevnorris closed this Apr 15, 2015

@jbergstroem

This comment has been minimized.

Show comment
Hide comment
@jbergstroem

jbergstroem Apr 16, 2015

Member

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

Member

jbergstroem commented Apr 16, 2015

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

@rvagg

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Apr 16, 2015

Member

@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

Member

rvagg commented Apr 16, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Apr 16, 2015

Contributor

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

Contributor

trevnorris commented Apr 16, 2015

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

@jbergstroem

This comment has been minimized.

Show comment
Hide comment
@jbergstroem

jbergstroem Apr 16, 2015

Member

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?

Member

jbergstroem commented Apr 16, 2015

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?

chrisdickinson added a commit that referenced this pull request Apr 17, 2015

2015-04-17 io.js v1.8.0 Release
Notable Changes:

* build: Support for building io.js as a static library (Marat Abdullin) #1341
* deps: upgrade openssl to 1.0.2a (Shigeki Ohtsu) #1389
* npm: Upgrade npm to 2.8.3. (Forrest L Norvell) #1448
* src: allow multiple arguments to be passed to process.nextTick (Trevor Norris) #1077
* module: interaction of require('.') with NODE_PATH has been restored and deprecated.
  This functionality will be removed at a later point. (Roman Reiss) #1363

chrisdickinson added a commit that referenced this pull request Apr 17, 2015

2015-04-17 io.js v1.8.0 Release
Notable Changes:

* build: Support for building io.js as a static
  library (Marat Abdullin) #1341
* deps: upgrade openssl to 1.0.2a (Shigeki Ohtsu) #1389
* npm: Upgrade npm to 2.8.3. (Forrest L Norvell) #1448
* src: allow multiple arguments to be passed to
  process.nextTick (Trevor Norris) #1077
* module: the interaction of require('.') with NODE_PATH has been
  restored and deprecated. This functionality will be removed at
  a later point. (Roman Reiss) #1363
@KenanSulayman

This comment has been minimized.

Show comment
Hide comment
@KenanSulayman

KenanSulayman Apr 18, 2015

Contributor

🎉 🎉 Awesome! 🎉 🎉

Contributor

KenanSulayman commented Apr 18, 2015

🎉 🎉 Awesome! 🎉 🎉

chrisdickinson added a commit that referenced this pull request Apr 20, 2015

2015-04-20 io.js v1.8.1 Release
Notable Changes:

* build: revert vcbuild.bat changes
* changes inherited from v1.8.0:
  * build: Support for building io.js as a static
    library (Marat Abdullin) #1341
  * npm: Upgrade npm to 2.8.3. (Forrest L Norvell) #1448
  * deps: upgrade openssl to 1.0.2a (Shigeki Ohtsu) #1389
  * src: allow multiple arguments to be passed to
    process.nextTick (Trevor Norris) #1077
  * module: the interaction of require('.') with NODE_PATH has been
    restored and deprecated. This functionality will be removed at
    a later point. (Roman Reiss) #1363
@igl

This comment has been minimized.

Show comment
Hide comment
@igl

igl Apr 23, 2015

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

igl commented Apr 23, 2015

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

@petkaantonov

This comment has been minimized.

Show comment
Hide comment
@petkaantonov

petkaantonov Apr 23, 2015

Contributor

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

Contributor

petkaantonov commented Apr 23, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment