lib: faster internal createBlob

[H4ad]

Inspired by nodejs/performance#109, I removed the usage of ReflectConstruct which is very heavy to call, and I also added a couple more benchmarks for blob.

Improvements:

 confidence improvement accuracy (*) (**) (***)
blob/creation.js kind='Blob' n=50000 0.02 % ±1.66% ±2.21% ±2.88%
blob/creation.js kind='createBlob' n=50000 *** 2727.18 % ±138.63% ±186.82% ±248.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

 confidence improvement accuracy (*) (**) (***)
blob/resolveObjectURL.js n=50000 *** 304.19 % ±11.73% ±15.80% ±20.95%
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 (*) (**) (***)
blob/slice.js dataSize=30720 n=50000 *** 445.71 % ±32.71% ±44.06% ±58.44%
blob/slice.js dataSize=5 n=50000 *** 456.75 % ±22.46% ±30.25% ±40.13%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***

I also think we can improve ClonedBlob but I tried using Function and also Class inheritance but I was not able to make it work correctly, but we probably can improve by 50% if we can make a version without ReflectConstruct.

cc @nodejs/performance

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[rluvaton]

I'm happy to see my PR inspired this 😀

[RafaelGSS]

LGTM

[nodejs-github-bot]

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

[RafaelGSS]

Benchmark CI https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1402/

[rluvaton]

It looks like the benchmark CI was stuck (nothing changed for 8 hours)

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

[H4ad]

@rluvaton Can you cancel and start again? I lowered the values of the benchmark for blob and file, because of the regression found on nodejs/performance#118

[rluvaton]

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

[H4ad]

This piece of code:

constbuff=Buffer.allocUnsafe(1024**2);constsource=newFile(buff,'dummy.txt',options);constnow=performance.now();source.text().then(()=>console.log(`diff: ${performance.now()-now}`));

Takes 3s to run, and running 1e3 will take a looong time, I will update the benchmark again, sorry for that.

[nodejs-github-bot]

Landed in 328bdac...1a839f3

[tniessen]

@anonrig FWIW, none of the three commits that were merged here adhere to our commit message guidelines.

[anonrig]

@anonrig FWIW, none of the three commits that were merged here adhere to our commit message guidelines.

Is this a bug with node-core-utils? It seems we shouldn't even land commit that adhere.

[aduh95]

Reviewing the commit message is the burden of the PR author and the reviewers, NCU can only catch a subset of commit message "violation" – in this case, it would be very hard for NCU to guess that added, faster, and improved are not imperative verbs.

[Uzlopak]

The problem is that the length of the first commit message was reported to be too long. So something should have errored like when you dont prefix the First commit message with util: or so.