timers: enable timers to be used as primitives by bmeck · Pull Request #19683 · nodejs/node · GitHub

For web compatibility this allows timers to be stored as the key
of an Object property and be passed back to corresponding method to
clear the timer.

Note that this is using the async_id_symbol to get a numeric ID to correspond with timers.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

For web compatibility this allows timers to be stored as the key of an Object property and be passed back to corresponding method to clear the timer.

Can we do the caching in [@@toPrimitive]()? I doubt this is a very frequently used feature, so it might be good if we could avoid the storage overhead for the common case?

seems fine to change that.

not sure how we could easily avoid the delete though when clearing without doing some funny stuff. the cache should swap into dictionary mode really fast though.

Did you check benchmarks?

@mscdex I did not. I would be very surprised if it has any significant impact.

LGTM if the benchmarks are happy

This is semver-minor, right? Should we document this?

I think we may want to avoid accessing global.clearInterval here … maybe doing something like we do for clearTimeout, i.e. const clearInterval = exports.clearInterval = … is a good idea here too?

ah yes, that would be a bug if that happened. I'm not 100% sure on why these functions are not named looking at them...

I ran ./node benchmark/run.js timers but am not seeing anything changing within margin of error.

@bmeck You may already know this, but in case not: If you have a binary compiled from master called node-old and a binary compiled with your changes called node-new, you can have it do the statistical computation for you with something like:

node benchmark/compare.js --old node-old --new node-new timers > my-benchmark.csv

...followed by...

cat my-benchmark.csv | Rscript compare.R

See https://github.com/nodejs/node/blob/master/doc/guides/writing-and-running-benchmarks.md#comparing-nodejs-versions for more information.

(Edited above to include correct command...)

CI: https://ci.nodejs.org/job/node-test-commit/17271/
Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/145/

Nit: Please wrap at 80 characters :)

fixed

Would timer = KNOWN_TIMERS[timer] work? This would avoid a recursion.

fixed

Wrap at 80 cols.

fixed

Put

* Returns: {integer}

right below the heading.

fixed

Extraneous line.

fixed

Why @@toPrimitive rather than valueOf?

see https://codepen.io/bradleymeck/pen/eMMpdR?editors=0012 , .valueOf is not safe for using as a key. toPrimitive handles both string and number coercion.

There's one significant drop showing in the benchmark CI:

                                          confidence improvement accuracy (*)    (**)   (***)
[...]
timers/timers-cancel-pooled.js millions=5        ***    -48.32 %      ±11.22% ±15.03% ±19.77%

I guess we have to make a call deciding whether we're okay with that?

-1 if we're going to see a performance regression like that

It is probably from the uncondition delete in the cancel. We could replace timer.close when toPrimitive is called and make that more conditional at the cost of some odd things possibly showing up if people replace timer.close with a custom function and don't expect us to wrap it. I'll munge with this a bit and see if we can fix up that cliff. Not sure why my test wasn't showing it.

This won't pass linting due to missing semicolon. Also, can the function be factored out?

fixed / it cannot be factored out since it closes over $close.

$close is effectively always equal to Timeout.prototype.close, right?

since it is public and mutable, that is not certain.

@bmeck I think it’s fine to just ignore that. You could still run into it anyway, when .close is changed after the [@@toPrimitive]() call…

if they replace it they are probably wrapping it, I'm already ignoring all the ways to avoid getter/setters but don't feel comfortable with completely removing .close this seems like one of the metrics people could be profiling handle lifetimes.

Why the addition of clearInterval variable? Doesn't seem used anywhere.

was added in e32b969 as a bug fix to previous iteration

This fails linting.

fixed

@mscdex with the most change can you recheck your perf concerns?

Benchmarks again: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/151/

So - this does seem more useful than I thought. (With a request, like a session, you might need to store it in e.g. Redis.)

I'm going to guess the perf drop is due to some polymorphism? Maybe we should run turbolizer against it. I'm not yet going to unblock this yet but I wonder if the perf hit is really that much overall.

We should stress HTTP and see if cancel ticks go up significantly, I suppose.

Can you check that +timeout1 === timeout1[Symbol.toPrimitive]()?

@bmeck I have a suggestion to make, if I may:

We can still get the functionality here while delaying perf concerns in the following way:

Keep the toPrimitive
Remove the id detection / polymorphism from existing timers methods
Add a getTimerById (or similar) to get a timer object by the primitive id

This has the following advantages:

Allows the funcionality
Avoids polymorphism & existing perf concerns
Allows timers to be refreshed from id (see [DEP0096] DeprecationWarning: timers.unenroll() question #20261 (comment))

If you're still interested, I would gladly review that kind of update. If not, mind if I take the existing commits and adjust?

Im on vacation but would object to those suggested differences.

…

On Thu, Apr 26, 2018, 12:43 AM Jeremiah Senkpiel ***@***.***> wrote: @bmeck <https://github.com/bmeck> I have a suggestion to make, if I may: We can still get the functionality here while delaying perf concerns in the following way: - Keep the toPrimitive - Remove the id detection / polymorphism from existing timers methods - Add a getTimerById (or similar) to get a timer object by the primitive id This has the following advantages: - Allows the funcionality - Avoids polymorphism & existing perf concerns - Allows timers to be refreshed from id (see #20261 (comment) <#20261 (comment)>) If you're still interested, I would gladly review that kind of update. If not, mind if I take the existing commits and adjust? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19683 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOUo9g2Dh_7r20OAuAmEcJDcQNZO8aUks5tsJmtgaJpZM4TA7q-> .

@bmeck if you still want to pursue this, instead of doing the more expensive in check — you could just set a flag when a timer is converted to a number. In addition, the check within clearTimeout could be reversed. First check whether timer is true & has _onTimeout, then do the typeof check (get the timer, etc.) and call clearTimeout again with the result.

I'd love to see how @apapirovski's suggestions work out.

@bmeck Do you want to continue on this or can I take over basing on top of your commit (with credit preserved)? I like the idea but I think I've got some solid ideas on how to make it faster, as expressed above.

@apapirovski please take it over, your work is quite exciting :)

@bmeck thanks! I'll pull in your commit and build on top of it. 👍 I'll preserve the credit when/if I open a PR, depending on how the perf works out.

I'll close this out since there's a more up-to-date / rebased version. Hopefully we can sort out the remaining issues to land it.

timers: enable timers to be used as primitives

9ac2bd4

For web compatibility this allows timers to be stored as the key of an Object property and be passed back to corresponding method to clear the timer.

nodejs-github-bot added the timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. label Mar 29, 2018

bmeck requested review from addaleax and trevnorris March 29, 2018 20:25

addaleax reviewed Mar 29, 2018

View reviewed changes

move cache assignment to toPrimitive call

6101d52

addaleax approved these changes Mar 29, 2018

View reviewed changes

addaleax added the semver-minor PRs that contain new features and should be released in the next minor version. label Mar 29, 2018

doc && fix bug

e32b969

addaleax approved these changes Mar 29, 2018

View reviewed changes

TimothyGu reviewed Mar 29, 2018

View reviewed changes

bmeck added 2 commits March 29, 2018 17:41

nits

c4ec0e5

nits

d963047

mscdex suggested changes Mar 29, 2018

View reviewed changes

only delete if put into cache

54b8894

TimothyGu reviewed Mar 30, 2018

View reviewed changes

linting

d7ae747

Fishrock123 reviewed Apr 11, 2018

View reviewed changes

Fishrock123 mentioned this pull request Apr 25, 2018

[DEP0096] DeprecationWarning: timers.unenroll() question #20261

Closed

apapirovski mentioned this pull request Jun 5, 2018

timers: allow timers to be used as primitives #21152

Closed

4 tasks

apapirovski closed this Jun 25, 2018

               // Schedule or re-schedule a timer.
               // The item must have been enroll()'d first.
               const active = exports.active = function(item) {
+                KNOWN_TIMERS[item[async_id_symbol]] = item;

               exports.clearInterval = function(timer) {
+                if (typeof timer === 'number' || typeof timer === 'string') {
+                  if (timer in KNOWN_TIMERS) {
+                    clearInterval(KNOWN_TIMERS[timer]);

+              const clearInterval = exports.clearInterval = function(timer) {
+                if (typeof timer === 'number' || typeof timer === 'string') {
+                  if (timer in KNOWN_TIMERS) {
+                    clearInterval(KNOWN_TIMERS[timer]);


		### timeout[Symbol.toPrimitive]()

		When coercing a `Timeout` to a primitive, a primitive will be generated that can be used with the appropriate function that can be used to clear the `Timeout`. This allows enhanced compatibility with browser `setTimeout`, and `setInterval` implementations.


		When coercing a `Timeout` to a primitive, a primitive will be generated that can be used with the appropriate function that can be used to clear the `Timeout`. This allows enhanced compatibility with browser `setTimeout`, and `setInterval` implementations.

		Returns a `number`.

		const unrefedLists = Object.create(null);

		const KNOWN_TIMERS = Object.create(null);

                 return true;
               }
+              Timeout.prototype[Symbol.toPrimitive] = function() {

+                    delete KNOWN_TIMERS[this[async_id_symbol]];
+                    this.close = $close;
+                    this.close();
+                  }


		assert.strictEqual(Number.isNaN(+timeout1), false);
		assert.strictEqual(Number.isNaN(+timeout2), false);

timers: enable timers to be used as primitives by bmeck · Pull Request #19683 · nodejs/node · GitHub

Uh oh!

Uh oh!

timers: enable timers to be used as primitives - #19683

timers: enable timers to be used as primitives#19683bmeck wants to merge 7 commits intonodejs:masternodejs/node:masterfrom bmeck:timeout-toPrimitivebmeck/node:timeout-toPrimitiveCopy head branch name to clipboard

Conversation

bmeck commented Mar 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mscdex commented Mar 29, 2018

Uh oh!

bmeck commented Mar 29, 2018

Uh oh!

addaleax left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bmeck commented Mar 29, 2018

Uh oh!

Trott commented Mar 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Trott commented Mar 29, 2018

Uh oh!

addaleax left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

addaleax commented Mar 29, 2018

Uh oh!

mscdex left a comment

Choose a reason for hiding this comment

Uh oh!

bmeck commented Mar 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bmeck Mar 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bmeck Mar 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

timers: enable timers to be used as primitives#19683
bmeck wants to merge 7 commits into
nodejs:masterfrom
bmeck:timeout-toPrimitive

bmeck commented Mar 29, 2018 •
edited
Loading

Trott commented Mar 29, 2018 •
edited
Loading

bmeck commented Mar 30, 2018 •
edited
Loading

bmeck Mar 30, 2018 •
edited
Loading

bmeck Mar 30, 2018 •
edited
Loading

mscdex commented Apr 3, 2018 •
edited
Loading