buffer,util: refactor for performance

[Trott]

internal/util.js definied toInteger() and toLength() but they were only
used by lib/buffer.js. Inlining these small functions results in a small but
statistically-significant performance gain.

Checklist

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

Affected core subsystem(s)

buffer util

[Trott]

$ node benchmark/compare.js --old /var/tmp/node-master --new /var/tmp/node-new --filter buffer-from --set 'source=arraybuffer' --set 'source=arraybuffer-middle' buffers > /var/tmp/compare.csv[00:01:09|% 100| 1/1 files | 60/60 runs | 4/4 configs]: Done $ cat /var/tmp/compare.csv | Rscript benchmark/compare.R  improvement confidence p.value buffers/buffer-from.js n=1024 len=10 source="arraybuffer-middle" 7.12 % *** 1.415439e-18 buffers/buffer-from.js n=1024 len=10 source="arraybuffer" 0.05 % 9.482883e-01 buffers/buffer-from.js n=1024 len=2048 source="arraybuffer-middle" 4.91 % ** 2.134363e-03 buffers/buffer-from.js n=1024 len=2048 source="arraybuffer" 0.94 % 2.267840e-01 $

[Trott]

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

[cjihrig]

I thought the idea was to use these in other places @thefourtheye ?

[jasnell]

@cjihrig ... I'm sure it could be, but until there's a need for that, this should be fine. We can revert this if it proves necessary.

[jasnell]

Landed in 1e6186e

[italoacasas]

cc @Trott

[Trott]

@italoacasas#12328

[MylesBorins]

should we backport to v6.x? I've added the baking label as we should wait a bit if it is going to land

[thefourtheye]

I am going to take a wild guess here. The performance improvement seen here could be because of the hidden isNaN check. The idea was to standardise buffer checks and toInteger could be used everywhere else.

[Trott]

@MylesBorins Backport to v6.x PR: #13046