buffer: improve performance of multiple Buffer operations by thisalihassan · Pull Request #61871 · nodejs/node

thisalihassan · 2026-02-17T21:33:58Z

Summary

Multiple performance improvements to Buffer operations, verified with benchmarks (15-30 runs, comparing old vs new binaries built from same tree).

Changes

Buffer.copyBytesFrom() (+100-210%)
Avoid intermediate TypedArrayPrototypeSlice allocation by calculating byte offsets directly into the source TypedArray's underlying ArrayBuffer.

Buffer.prototype.fill("t", "ascii") (+26-37%)

ASCII indexOf (+14-46%)
Call indexOfString directly for ASCII encoding instead of first converting the search value to a Buffer via fromStringFast and then calling indexOfBuffer. ASCII and Latin-1 share the same byte values for characters 0-127.

swap16/32/64 (+3-38%)
Add V8 Fast API C++ functions (FastSwap16/32/64) alongside the existing slow path. Largest gains at len=256 (+35%).

Benchmark results

Key results (15-30 runs, *** = p < 0.001):

Benchmark	Improvement
copyBytesFrom (offset, Uint8Array, len=256)	+210% ***
copyBytesFrom (offset+length, Uint8Array, len=256)	+206% ***
swap16 len=256	+38% ***
fill("t", "ascii") size=8192	+37% ***
indexOf ASCII 'Alice'	+46% ***
indexOf ASCII '@'	+31% ***
fill("t", "ascii") size=65536	+26% ***
swap64 len=768 aligned	+12% ***

No regressions observed. Full benchmark CSV attached.
compare-all-buffers-final.csv

nodejs-github-bot · 2026-02-17T21:34:03Z

Review requested:

@nodejs/performance

- copyBytesFrom: calculate byte offsets directly instead of slicing into an intermediate typed array - toString('hex'): use V8 Uint8Array.prototype.toHex() builtin - fill: add single-char ASCII fast path - indexOf: use indexOfString directly for ASCII encoding - swap16/32/64: add V8 Fast API functions

lib/buffer.js

Renegade334 · 2026-02-17T21:50:59Z

src/node_buffer.cc

+void FastSwap16(Local<Value> receiver,
+                Local<Value> buffer_obj,
+                // NOLINTNEXTLINE(runtime/references)
+                FastApiCallbackOptions& options) {
+  HandleScope scope(options.isolate);
+  ArrayBufferViewContents<char> buffer(buffer_obj);
+  CHECK(nbytes::SwapBytes16(const_cast<char*>(buffer.data()), buffer.length()));
+}


These fast callbacks are non-identical to the conventional callbacks they shadow.

The existing callbacks validate their argument and throws to JS if invalid, whereas your fast callbacks hard-crash the process. It might be better to validate in the JS layer, then use the same unwrapping logic on both sides.

Your fast callback cannot have a different return convention to the conventional callback. You will need to remove the return value from the conventional callback.

Renegade334 · 2026-02-17T22:27:44Z

lib/buffer.js

Same behaviour AFAICT, but encodingsMap.ascii seems more appropriate.

Yes same behaviour IndexOfString only has branches for UCS2, UTF8, and Latin1, Adding an ASCII branch to IndexOfString would just be a duplicate of the Latin1 branch since ASCII is a subset of Latin1.

That's my point, these are still discrete encodings even though the behaviour here is the same, so this should pass encodingsMap.ascii to the binding and IndexOfString should add a condition to send this down the same path.

Done @Renegade334

Renegade334 · 2026-02-17T22:37:01Z

src/node_buffer.cc

+void FastSwap16(Local<Value> receiver,
+                Local<Value> buffer_obj,
+                // NOLINTNEXTLINE(runtime/references)
+                FastApiCallbackOptions& options) {
+  HandleScope scope(options.isolate);
+  ArrayBufferViewContents<char> buffer(buffer_obj);
+  CHECK(nbytes::SwapBytes16(const_cast<char*>(buffer.data()), buffer.length()));
+}


Fast callbacks should include debug tracking and call tests.

Thanks for sharing these I will update the code

codecov · 2026-02-17T23:10:45Z

Codecov Report

❌ Patch coverage is 89.70588% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.72%. Comparing base (4f13746) to head (59f5d09).
⚠️ Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_buffer.cc	72.00%	0 Missing and 7 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #61871   +/-   ##
=======================================
  Coverage   89.72%   89.72%           
=======================================
  Files         675      675           
  Lines      204806   204875   +69     
  Branches    39355    39369   +14     
=======================================
+ Hits       183761   183824   +63     
+ Misses      13330    13329    -1     
- Partials     7715     7722    +7

Files with missing lines	Coverage Δ
lib/buffer.js	`99.78% <100.00%> (+<0.01%)`	⬆️
src/node_buffer.cc	`68.06% <72.00%> (+0.08%)`	⬆️

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

- Guard ensureUint8ArrayToHex against --no-js-base-64 flag by falling back to C++ hexSlice when toHex is unavailable - Remove THROW_AND_RETURN_UNLESS_BUFFER and return value from slow Swap16/32/64 to match fast path conventions (JS validates) - Add TRACK_V8_FAST_API_CALL to FastSwap16/32/64 - Add test/parallel/test-buffer-swap-fast.js for fast API verification

Renegade334 · 2026-02-18T00:08:19Z

src/node_buffer.cc

ArrayBufferViewContents is wrong here, as buffer.data() may be a stack-allocated copy of the byte data rather than the data itself. SPREAD_BUFFER_ARG is the correct macro to use here, as per the conventional callback.

@Renegade334 replaced ArrayBufferViewContents with SPREAD_BUFFER_ARG in all three fast swap callbacks

lib/buffer.js

ChALkeR

For toHex, wait until #61609, which improves native perf significantly (more than Uint8Array.prototype.toHex)

See also #60249 (comment)

ChALkeR · 2026-02-18T03:34:33Z

lib/buffer.js

    } else if (value.length === 1) {
      // Fast path: If `value` fits into a single byte, use that numeric value.
-      if (normalizedEncoding === 'utf8') {
+      if (normalizedEncoding === 'utf8' || normalizedEncoding === 'ascii') {


Currently, ascii behaves exactly like latin1
Unsure if by design or accidentally

yes, this is safe by design I am just extending the existing single byte numeric optimization to cover ASCII, since the guard already constrains it to the valid ASCII range.

thisalihassan · 2026-02-18T07:21:23Z

Note on toBase64 / toBase64url:

I also tried replacing the C++ base64Slice/base64urlSlice bindings with V8's Uint8Array.prototype.toBase64() (similar to the toHex change) but it caused a 35-54% regression across all buffer sizes so I reverted base64/base64url and kept only the toHex optimization which showed a clear +26-37% win.

ChALkeR · 2026-02-18T07:31:15Z

@thisalihassan toHex doesn't show a win anymore with nbytes update which should soon land (as it landed in nbytes)

Instead, it's ~3x slower.

See nodejs/nbytes#12

thisalihassan · 2026-02-18T08:06:14Z

Hi @ChALkeR thanks for flagging I was not aware. I benchmarked the nibble approach locally and it's indeed a much bigger win (~3x vs my ~30% with toHex). Reverted the toHex path entirely the other changes in this PR are unaffected.

Should I include the nbytes nibble HexEncode optimization in this PR or keep them as separate PRs?

~~PS: One test is failing /test/parallel/test-debugger-restart-message.js I believe it's known mac issue and unrelated to my changes~~

Remove V8 Uint8Array.prototype.toHex() path for Buffer.toString('hex') in favour of the upcoming nbytes HexEncode improvement (nodejs/nbytes#12) which is ~3x faster through the existing C++ hexSlice path. Refs: nodejs/nbytes#12

lib/buffer.js

anonrig · 2026-02-18T19:41:10Z

src/node_buffer.cc

-  Environment* env = Environment::GetCurrent(args);
-  THROW_AND_RETURN_UNLESS_BUFFER(env, args[0]);


Why did we remove these lines?

_swap16 is an internal binding and this is always a Buffer, so the THROW_AND_RETURN_UNLESS_BUFFER check could never fail also removed Environment since it was only needed by that macro.

anonrig · 2026-02-18T19:41:52Z

test/parallel/test-buffer-swap-fast.js

Each of these methods should test the output of relevant swrap methods.

Done each test now verifies the swapped output

can you please re-review when you get time?

anonrig · 2026-02-18T19:42:22Z

lib/buffer.js

    } else if (value.length === 1) {
      // Fast path: If `value` fits into a single byte, use that numeric value.
-      if (normalizedEncoding === 'utf8') {
+      if (normalizedEncoding === 'utf8' || normalizedEncoding === 'ascii') {


Please update comment to why we can add ASCII here.

anonrig · 2026-02-18T19:42:52Z

lib/buffer.js

    if (length !== undefined) {
      validateInteger(length, 'length', 0);
-      end = offset + length;
+      end = MathMin(offset + length, viewLength);


Can you add a comment to why we have this change now?

Sure, the clamping is required because we switched from TypedArrayPrototypeSlice (which clamped silently)

nodejs-github-bot added buffer Issues and PRs related to the buffer subsystem. c++ Issues and PRs that require attention from people who are familiar with C++. needs-ci PRs that need a full CI run. labels Feb 17, 2026

thisalihassan force-pushed the buffer-perf-improvements branch from d2ba38f to 495feb5 Compare February 17, 2026 21:41

Renegade334 reviewed Feb 17, 2026

View reviewed changes

Renegade334 added performance Issues and PRs related to the performance of Node.js. needs-benchmark-ci PR that need a benchmark CI run. labels Feb 17, 2026

thisalihassan force-pushed the buffer-perf-improvements branch 3 times, most recently from 64a4b55 to 1395d2f Compare February 17, 2026 23:41

thisalihassan force-pushed the buffer-perf-improvements branch from 1395d2f to 01ba74f Compare February 17, 2026 23:42

Renegade334 reviewed Feb 18, 2026

View reviewed changes

ChALkeR reviewed Feb 18, 2026

View reviewed changes

buffer: revert toHex in favour of nbytes HexEncode update

c705a5d

Remove V8 Uint8Array.prototype.toHex() path for Buffer.toString('hex') in favour of the upcoming nbytes HexEncode improvement (nodejs/nbytes#12) which is ~3x faster through the existing C++ hexSlice path. Refs: nodejs/nbytes#12

thisalihassan requested review from ChALkeR and Renegade334 February 18, 2026 08:10

thisalihassan added 2 commits February 18, 2026 13:14

resolve feedback

6b3cf03

resolve feedback on fast callbacks

f5c875b

anonrig reviewed Feb 18, 2026

View reviewed changes

added comments and updated tests

59f5d09

thisalihassan requested a review from anonrig February 18, 2026 21:42

		Environment* env = Environment::GetCurrent(args);
		THROW_AND_RETURN_UNLESS_BUFFER(env, args[0]);

Uh oh!

Conversation

thisalihassan commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Benchmark results

Uh oh!

nodejs-github-bot commented Feb 17, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ChALkeR left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thisalihassan Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thisalihassan commented Feb 18, 2026

Uh oh!

ChALkeR commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thisalihassan commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Comments

thisalihassan commented Feb 17, 2026 •

edited

Loading

codecov bot commented Feb 17, 2026 •

edited

Loading

ChALkeR left a comment •

edited

Loading

thisalihassan Feb 18, 2026 •

edited

Loading

ChALkeR commented Feb 18, 2026 •

edited

Loading

thisalihassan commented Feb 18, 2026 •

edited

Loading