timers: minor refinements to TimersList & stricter undefined/null checks

[apapirovski]

A few small refinements to TimersList & ImmediateList:

• Eliminate the createTimersList helper function and instead do all instantiation directly within the constructor
• Define TIMEOUT_MAX as 2 ** 31 - 1 instead of having a comment explaining it
• No longer use delete on unrefed & refed lists as it's expensive and offers no benefit since we never iterate over the dictionary object in regular usage, except in cases where user-code throws and we can likely accept the minute difference in performance in those cases
• Stricter comparisons to null & undefined

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

timers

[apapirovski]

CI: https://ci.nodejs.org/job/node-test-pull-request/11855/

[mscdex]

Not using delete could leave a lot of entries in the various list objects. This is why we use delete in EventEmitter for example.

[apapirovski]

Not using delete could leave a lot of entries in the various list objects.

Yes but in practical terms this has basically no impact. I've tested access performance on an Object with 1e7 keys and 1e2 keys and it's constant. It's also likely that the keys will be pretty predictable since they're based on user code and unlikely to be random numbers, so constantly deleting and adding them is not really helping anyone.

This is why we use delete in EventEmitter for example.

And that is also being removed in #17324. As far as I can see, we're just sabotaging performance by using delete on Objects that are never iterated over and are likely to have a predictable list of properties.

[apapirovski]

@mscdex Btw if there's a legitimate reason to not do this that I'm missing, I'm definitely all ears and will remove that change. I just haven't found it in my testing... And that also applies to the events PR linked above. Thanks for the feedback!

[Trott]

Maybe run benchmark/timers on this?

[apapirovski]

@Trott yeah, it's running right now. Forgot to post a link.

https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/69/console

[Trott]

LGTM if benchmarks and CI are OK.

[lpinca]

@apapirovski is memory usage the same without delete?

[mscdex]

@apapirovski My concern was not about performance, but memory usage.

IMHO it is not safe to make any assumptions about what gets passed to setTimeout(), etc. as far as the timeout value goes.

[mscdex]

And that is also being removed in #17324

I did not realize that until now, that is a bad idea IMHO. Even third-party EventEmitter implementations that used to do this switched to delete because of memory issues.

[apapirovski]

I did not realize that until now, that is a bad idea IMHO. Even third-party EventEmitter implementations that used to do this switched to delete because of memory issues.

Addressed. I did actually look at memory as an issue but I think I had my iterations set too low. Once I bumped it up enough, I'm seeing regressions in performance too — not just memory.

That said, if our policy is that we don't want to assume end-user input then delete cannot be removed — I don't think the memory issue can ever possibly be optimized enough.

Same as events, I think I was too optimistic re: user input being constant (to an extent).

[apapirovski]

CI: https://ci.nodejs.org/job/node-test-pull-request/11940/

[apapirovski]

@lpinca would you mind reviewing this given your prior comment here? The delete issue has been resolved. Thanks!

[lpinca]

SGTM.

[apapirovski]

Landed in e55b7d6