Repository navigation
timers: recent performance regressions #41219
Description
Activity
To mitigate this, we can traverse
for the Timeouts andLine 161 in c8f5dd6
for the Immediates. That way, we wouldn't have to run any extra code when the timers are added/removed. The results are going to be a little less accurate because these objects aren't updated at the right moment always (which is why I didn't do it that way in #40813) but we can always fix that in a separate PR.Line 426 in c8f5dd6
we can always fix that in a separate PR
And if we can't fix it, we can always just leave it documented as an API limitation.
Reacted by Darshan Sen- added a commit that references this issue
on Dec 31, 2021 - added a commit that references this issue
on Jan 2, 2022 - added a commit that references this issue
on Jan 14, 2022 - added a commit that references this issue
on Jan 31, 2022 - added a commit that references this issue
on Feb 1, 2022
0d9f3bd introduced a noticeable performance regression with various timers benchmarks. For example:
timers/immediate.js type="clear"performance dropped 77%timers/timers-cancel-pooled.jsperformance dropped 55%timers/timers-timeout-pooled.jsperformance dropped 41%and many other timers benchmarks/benchmark configs saw double digit drops.
While having a public "get active requests"/"get active handles" API would be nice, I don't think it is worth this kind of penalty if we can't find some way to remedy the performance regressions.
/cc @RaisinTen