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