src: improve utf8 string generation performance

[anonrig]

This speeds up Utf8Value across all Node.js codebase. We add a fast path for one byte strings and use the new V8 API (String::ValueView) with simdutf for non-byte strings. Once simdutf supports null termination and invalid character replacement, we can improve the performance more.

cc @nodejs/performance @lemire

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

[github-actions]

Failed to start CI

- Validating Jenkins credentials
✔  Jenkins credentials valid
- Starting PR CI job
✘  Failed to start PR CI: 400 Bad Request

https://github.com/nodejs/node/actions/runs/10795045779

[jasnell]

CI failures look relevant to this change.

[lemire]

CI failures look relevant to this change.

Oh no.

[RafaelGSS]

Since the PR is claiming for performance, we should have benchmarks.

[codecov]

Codecov Report

Attention: Patch coverage is 84.61538% with 4 lines in your changes missing coverage. Please review.

Project coverage is 88.08%. Comparing base (9db6327) to head (4b28cf1).
Report is 271 commits behind head on main.

Files with missing lines	Patch %	Lines
src/string_bytes.cc	66.66%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #54873      +/-   ##
==========================================
+ Coverage   88.05%   88.08%   +0.02%     
==========================================
  Files         651      651              
  Lines      183405   183551     +146     
  Branches    35822    35867      +45     
==========================================
+ Hits       161499   161676     +177     
+ Misses      15159    15133      -26     
+ Partials     6747     6742       -5     

Files with missing lines	Coverage Δ
src/util.cc	87.34% <100.00%> (+0.32%)	⬆️
src/string_bytes.cc	68.43% <66.66%> (+4.48%)	⬆️

... and 50 files with indirect coverage changes

[anonrig]

Since the PR is claiming for performance, we should have benchmarks.

I don't know how to have an isolated benchmark for this. Any recommendations @RafaelGSS?

[RafaelGSS]

I don't know how to have an isolated benchmark for this.

So, how do you know this PR is improving performance then?

Any recommendations?

I suspect if you measure any public API that makes use of this new branch behind the scenes you should get a feasible result

[mcollina]

RSLGTM

[RafaelGSS]

@RafaelGSS I didn't forgot your comment. I've already attached a benchmark ci run to the description. it doesn't effect all paths only latin1 paths and it shows up to 7-8% improvement.

I might be missing something, but the benchmark result doesn't show any improvement if you consider the standard deviation. It also shows some regressions though.

[lemire]

@anonrig @RafaelGSS There is no harm at all in taking extra time.

Views have tremendous potential to speed up Node will lowering its memory usage. But as with all new things, it will take time to understand how to use it best in the Node code base.

[lemire]

@anonrig @RafaelGSS (By extra time, I meant days, not months.)

[anonrig]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[anonrig]

@ronag Can you review?

[nodejs-github-bot]

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

Addressed the recommendation. Dismissing.

[nodejs-github-bot]

Landed in 8191e1f