perf_hooks: reduce overhead of createHistogram

[H4ad]

Continuing the work started on nodejs/performance#109

 confidence improvement accuracy (*) (**) (***)
perf_hooks/histogram-clone.js n=100000 *** 102.24 % ±1.15% ±1.53% ±2.00%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 1 comparisons, you can thus
expect the following amount of false-positive results:
0.05 false positives, when considering a 5% risk acceptance (*, **, ***),
0.01 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

 confidence improvement accuracy (*) (**) (***)
perf_hooks/histogram-create.js n=100000 *** 30.19 % ±0.50% ±0.66% ±0.87%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 1 comparisons, you can thus
expect the following amount of false-positive results:
0.05 false positives, when considering a 5% risk acceptance (*, **, ***),
0.01 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

/cc @nodejs/performance

[anonrig]

This ReflectConstruct can be removed as well

[H4ad]

Yeah, but since it is not exposed directly I didn't think that was worth it, if not for spec compliance, this code could be removed (I think).

[Qard]

LGTM, with a minor nit.

[mcollina]

lgtm

[H4ad]

Someone can add author ready?

[nodejs-github-bot]

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

[H4ad]

I added another commit to try address https://ci.nodejs.org/job/node-test-commit-linux/nodes=ubuntu1804-64/54333/console, I think now both functions are optimized, it is causing an issue with v8 dead code.

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[RafaelGSS]

@H4ad Why this was landed with rebase? It doesn't contain atomic/independent commits that pass the tests according to our contribution guidelines. It also includes a fixup commit to the main queue. Please, use commit-queue-squash for these situations.

[H4ad]

My idea was to ship both commits since I initially thought they should be independent, but thinking more about the reason why I had the commit of test: avoid... was due to the optimization made by the previous commit that caused a test to be flaky, maybe all those commits were better to be landed in just one commit.

But making all the tests pass for each commit that will land in the same PR is something I misread from the guidelines, in case I need to do that, how do I ensure all the tests will pass for previous commits, should I call the job request-ci for each commit?

[RafaelGSS]

Usually, you guarantee by running the tests on your machine. When you add the commit-queue-rebaseAdd this label to allow the Commit Queue to land a PR in several commits. each the commit shouldn't depend on a subsequent commit otherwise you'll make future git bisect very hard and potential conflicts resolutions when creating the release proposal difficult too - you can check the releases.md how we use git cherry-pick.

Reference: https://github.com/nodejs/node/blob/main/doc/contributing/pull-requests.md#commit-squashing

[aduh95]

I can confirm that the test suite passes on both commits that landed, so no bisect has been harmed :) The guidelines are vague on what constitutes an atomic commit, so it’s a judgement call to make and both decisions would have been correct: it could have landed as one commit, it could have landed as two commits.
FYI the CQ handles fixup commits fine (i.e. it squashes the fixup commit into the one it targets before pushing to main).

[UlisesGascon]

@H4ad this commit didn’t land cleanly on v20.x-staging. Could you please open a manual backport?