Refactor Timers #4007

Fishrock123 · 2015-11-24T17:15:03Z

Commit 1

Consolidates the implementation of regular and internal (_unrefActive)
timers.

Includes an optimization for listOnTimeout() that previously only
internal timers had. (_runOnTimeout)

Also includes some minor other cleanup.

Commit 2

Describes the How and Why of the timers implementation, as well as
adding comments in spots that should allow for an easier understanding
of what is going on.

The timers implementation is very efficient, at a cost.
That cost is readable understandability, and this aims to improve that.

cc @bnoordhuis / @piscisaureus / @trevnorris / @misterdjules / etc?

This attempts to improve the timers implementation by consolidating the internal and regular timer logic.

I have not yet run performance testing / profiling on this, so feel free to help me out there if you are able to but I will hopefully be able to get to it shortly.

Tests pass locally, CI: https://ci.nodejs.org/job/node-test-commit/1237/

cc @nodejs/documentation and @nodejs/inclusivity I'd like thoughts on the format of the comments and their content and if they fit in well as code comments, as well as how understandable this is to people who are unfamiliar with the code.

Fishrock123 · 2015-11-24T17:17:14Z

lib/timers.js

    list = new Timer();
+    if (unrefed) list.unref();
+    list._unrefed = unrefed;


There is possibly a better way of doing this.

In a nutshell we need to be able to tell if a specific list (TimerWrap) is (supposed to be) unrefed or not.

I'm not to worried about people messing with these top-level handles from C++ though.

Could just store a reference to lists so just have one-line delete instead of branch down there?

Make sure you add _unrefed = false or similar to the Timer constructor, or you're mutating the object map.

@alexlamsl like maybe _parent?

@trevnorris good catch.

Actually, that doesn't apply to Timer, this sets it on the list not the timer itself. :)

@Fishrock123 yes _parent sounds good, then down below you can do delete list._parent[msecs]; instead of

if (list._unrefed) { delete unrefedLists[msecs]; } else { delete refedLists[msecs]; }

@Fishrock123 isn't list a Timer object, as declared a few lines above?

@alexlamsl Ah, I thought he was referring to Timeout. This is a TimerWrap, imported as Timer.

@trevnorris were you referring to Timer, as in TimerWrap, or Timeout?

list = new Timer(); // <- whatever object is returned from here

EDIT: nm. forgot that Timer comes from node::TimerWrap::New() in src/timer_wrap.cc.

Fishrock123 · 2015-11-24T17:29:53Z

@sup & @beaugunderson Thanks, Atom's spelling detection isn't very good unfortunately. :(

ghost · 2015-11-24T17:33:10Z

@Fishrock123 overall, i have to say i'm very impressed. if only all lib files were documented this well...

the only thing i'd suggest is maybe having a kind of difficulty rating referring to how complex and hard to understand the code and the explaining comments are. sadly, you can't easily explain some things :(

but that's just an idea, and would maybe make more sense if, well, all lib files were documented this well.

LGTM once the spelling errors are fixed ^^

jscissr · 2015-11-24T17:33:41Z

lib/timers.js


+// Object maps containing linked lists of timers, keyed and sorted by their
+// duration in miliseconds.


typo: mili → milli

Trott · 2015-11-24T17:34:19Z

This is awesome. The resulting code is much easier to understand. The comments are helpful too.

alexlamsl · 2015-11-24T17:53:22Z

lib/timers.js

  const msecs = item._idleTimeout;
  if (msecs < 0 || msecs === undefined) return;

  item._idleStart = Timer.now();

  var list;
+  const lists = unrefed ? unrefedLists : refedLists;



Why not var list = lists[msecs] and save a branch clause below?

It might not exist yet, so we need to be able to check that make a new one if it does not exist yet.

What I meant is instead of

var list; const lists = ...; if (lists[msecs]) { list = lists[msecs]; } else { ... }

How about

const lists = ...; var list = lists[msecs]; if (!list) { ... }

Ah, that sounds good, yeah.

Fishrock123 · 2015-11-25T17:58:07Z

// The timers are distributed into separate lists by milliseconds primarly to
// reduce the impact of the linked list's O(n) (linear) insertion time.

This is incorrect, I am wrong. @piscisaureus was right about the efficiency of the regular timers impl.

Heck, even after all of this I still didn't clue 100% into why this was supposed to be so efficient.

insert() doesn't actually insert, it only appends to the linked list. That is, it follows the libev guide closer than I had previously understood.

Example:

You only ever need to append to a list of timers scheduled for 50ms because even if you schedule two timers at the same time, none will ever be sooner than that timeout time, or an existing timeout, within that 50ms list.

On timeout, we only need to check the start of the list for timers that need to timeout. This is because all of those timers will only ever have a 50ms timeout, and so any timers past the first one that we don't need to timeout yet will also have a due date later than the current timeout, since they are all 50ms and must have been scheduled later than we first timed out.

Fishrock123 · 2015-11-26T22:49:05Z

I have now updated the PR with comments now correctly describing how exactly it works.

All operations in the JavaScript layer are virtually constant time. What we have effectively acts as a timer wheel. I do not think it is possible to make a better overall implementation.

misterdjules · 2015-11-27T02:14:01Z

lib/timers.js

-          // is complete, but not by using whatever domain was left over
-          // when the timeout threw its exception.
-          var oldDomain = process.domain;
-          process.domain = null;


At first sight, it seems that not setting process.domain to null would break test/parallel/test-domain-exit-dispose-again.js now that #3990 landed.

Fishrock123 · 2015-11-27T14:55:58Z

@misterdjules hmmm, let's find out:

CI rebased onto master: https://ci.nodejs.org/job/node-test-pull-request/866/

misterdjules · 2015-11-27T17:23:50Z

@Fishrock123 Confirmed.

Fishrock123 · 2015-11-27T17:28:48Z

@misterdjules Indeed. New CI: https://ci.nodejs.org/job/node-test-pull-request/867/

misterdjules · 2015-11-27T18:05:49Z

lib/timers.js

+    if (!timer._onTimeout) continue;
+
+    var domain = timer.domain;
+    if (domain) {

      // v0.4 compatibility: if the timer callback throws and the


This comment is obsolete, and doesn't describe the current state of the code base. It seems that this PR is a good opportunity to remove it.

Noted, I'll take a look at it in detail.

Hmmm, the comment was originally added in b221fe9 and then updated for domains in 4401bb4. However, it used to continue.

I think I may have made a mistake here having it return as it it did in the original _unrefActive(), perhaps we are missing a test for this?

rvagg · 2016-02-27T00:23:43Z

So good, well done on making it to landing @Fishrock123! I now crown you the new king of timers 👑, we know who to send people to when they have questions.

jasnell · 2016-03-02T16:15:41Z

In generally I think this should actually be safe for both LTS and v5 but I'd like to see it sit for a bit to be sure there are no hidden regressions in here (there shouldn't be, I just prefer to be conservative about it).

jasnell · 2016-03-02T16:16:01Z

oh, and yes, great job @Fishrock123 ... this is good stuff.

Consolidates the implementation of regular and internal (_unrefActive) timers. Also includes a couple optimizations: - Isolates the try/catch from listOnTimeout() in a new tryOnTimeout(). - Uses a TimersList constructor as the base for linkedlists. Additionally includes other cleanup and clarification, such as a rename of "Timer" to "TimerWrap". PR-URL: #4007 Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]> Reviewed-By: Chris Dickinson <[email protected]>

Describes the How and Why of the timers implementation, as well as adding comments in spots that should allow for an easier understanding about what is going on. The timers implementation is very efficient, at a cost. That cost is readable understandability, and this aims to improve that. PR-URL: #4007 Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]> Reviewed-By: Chris Dickinson <[email protected]>

Consolidates the implementation of regular and internal (_unrefActive) timers. Also includes a couple optimizations: - Isolates the try/catch from listOnTimeout() in a new tryOnTimeout(). - Uses a TimersList constructor as the base for linkedlists. Additionally includes other cleanup and clarification, such as a rename of "Timer" to "TimerWrap". PR-URL: #4007 Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]> Reviewed-By: Chris Dickinson <[email protected]>

Describes the How and Why of the timers implementation, as well as adding comments in spots that should allow for an easier understanding about what is going on. The timers implementation is very efficient, at a cost. That cost is readable understandability, and this aims to improve that. PR-URL: #4007 Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]> Reviewed-By: Chris Dickinson <[email protected]>

MylesBorins · 2016-08-30T14:09:47Z

@Fishrock123 as v6 is getting quite close to becoming LTS I'm going to opt to keep these changes out of the v4 release line.

This is in no ways a final decision and if you believe they should land we should discuss it in the next LTS meeting. Thanks for the hard work on these changes!

Fishrock123 · 2016-08-30T14:11:43Z

@thealphanerd While this looks large, the impact on running programs is minimal but mostly positive.
¯_(ツ)_/¯

MylesBorins · 2016-08-30T14:27:16Z

@Fishrock123 would you be willing to open an issue on the LTS repo about the various timers changes for v4?

Fishrock123 added the timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. label Nov 24, 2015

Fishrock123 reviewed Nov 24, 2015
View reviewed changes

jscissr reviewed Nov 24, 2015
View reviewed changes

alexlamsl reviewed Nov 24, 2015
View reviewed changes

Fishrock123 force-pushed the refactor-timers branch from 2e798fa to 45c2266 Compare November 24, 2015 18:51

misterdjules reviewed Nov 27, 2015
View reviewed changes

Fishrock123 added a commit to Fishrock123/node-perf-results that referenced this pull request Nov 30, 2015

Perf profiling results for nodejs/node#4007

5c661ca

Fishrock123 mentioned this pull request Nov 30, 2015

timers: fix processing of nested same delay timers #3063

Closed

Fishrock123 closed this Feb 26, 2016

Fishrock123 mentioned this pull request Mar 1, 2016

Release proposal: v5.7.1 #5464

Merged

5 tasks

Fishrock123 added the dont-land-on-v5.x label Mar 1, 2016

jasnell added the lts-watch-v4.x label Mar 2, 2016

Fishrock123 removed the dont-land-on-v5.x label Mar 14, 2016

evanlucas mentioned this pull request Mar 14, 2016

Release proposal: v5.8.1 #5698

Closed

evanlucas mentioned this pull request Mar 14, 2016

v5.9.0 proposal #5702

Merged

MylesBorins mentioned this pull request Mar 21, 2016

LTS Meeting - 2016-03-21 nodejs/Release#89

Closed

MylesBorins mentioned this pull request Apr 18, 2016

LTS WG Meeting - 2016-04-25 nodejs/Release#95

Closed

misterdjules mentioned this pull request Jul 18, 2016

clearTimeout with invalid handle cause program runs longer #7722

Closed

MylesBorins added dont-land-on-v4.x and removed lts-agenda labels Aug 30, 2016

SimonWoolf mentioned this pull request Jun 19, 2017

Measure between whole iterations of the event loop ably-forks/event-loop-stats#1

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor Timers #4007

Refactor Timers #4007

Fishrock123 commented Nov 24, 2015

Fishrock123 Nov 24, 2015

alexlamsl Nov 24, 2015

trevnorris Nov 24, 2015

Fishrock123 Nov 24, 2015

Fishrock123 Nov 24, 2015

alexlamsl Nov 24, 2015

alexlamsl Nov 24, 2015

Fishrock123 Nov 24, 2015

trevnorris Nov 24, 2015

Fishrock123 commented Nov 24, 2015

ghost commented Nov 24, 2015

jscissr Nov 24, 2015

Trott commented Nov 24, 2015

alexlamsl Nov 24, 2015

Fishrock123 Nov 24, 2015

alexlamsl Nov 24, 2015

Fishrock123 Nov 24, 2015

Fishrock123 commented Nov 25, 2015

Fishrock123 commented Nov 26, 2015

misterdjules Nov 27, 2015

Fishrock123 commented Nov 27, 2015

misterdjules commented Nov 27, 2015

Fishrock123 commented Nov 27, 2015

misterdjules Nov 27, 2015

Fishrock123 Nov 27, 2015

Fishrock123 Dec 2, 2015

rvagg commented Feb 27, 2016

jasnell commented Mar 2, 2016

jasnell commented Mar 2, 2016

MylesBorins commented Aug 30, 2016

Fishrock123 commented Aug 30, 2016

MylesBorins commented Aug 30, 2016


		// Object maps containing linked lists of timers, keyed and sorted by their
		// duration in miliseconds.

Refactor Timers #4007

Refactor Timers #4007

Conversation

Fishrock123 commented Nov 24, 2015

Commit 1

Commit 2

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Fishrock123 commented Nov 24, 2015

ghost commented Nov 24, 2015

Choose a reason for hiding this comment

Trott commented Nov 24, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Fishrock123 commented Nov 25, 2015

Example:

Fishrock123 commented Nov 26, 2015

Choose a reason for hiding this comment

Fishrock123 commented Nov 27, 2015

misterdjules commented Nov 27, 2015

Fishrock123 commented Nov 27, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rvagg commented Feb 27, 2016

jasnell commented Mar 2, 2016

jasnell commented Mar 2, 2016

MylesBorins commented Aug 30, 2016

Fishrock123 commented Aug 30, 2016

MylesBorins commented Aug 30, 2016