Repository navigation
buffer: ~2x slowdown in master compared to v12.x #32226
Description
Activity
- addedbufferIssues and PRs related to the buffer subsystem.Issues and PRs related to the buffer subsystem.c++Issues and PRs that require attention from people who are familiar with C++.Issues and PRs that require attention from people who are familiar with C++.performanceIssues and PRs related to the performance of Node.js.Issues and PRs related to the performance of Node.js.
on Mar 12, 2020 @mscdex Can you provide the output
uname -a(what the issue template asks for forPlatform:)? Is this on arm/arm64/x86/x64/something else? That’s probably relevant here.Added.
Additionally, I'm using gcc 7.4.0 to compile if that matters.
Can you try #32116? If this is some regression on V8, it might already be fixed (or it might be worse on 8.1, but let's hope not).
The prof output makes it seem like the reason is that
std::shared_ptras we compile it on x64 seems to not use atomic instructions, but rather mutexes. I don’t quite know why it does that, but it’s probably something that can be addressed by passing compile flags. (That might be ABI-breaking but we could do it for v14.x, see #30786 for a related ARM issue.)Or it’s unrelated to that, but that’s not what the prof output says.
Reacted by mary marchini@mmarchini The V8 8.1 branch has the same performance as master.
Reacted by mary marchini(__gnu_cxx::_Lock_policy)2is_S_atomic, though, so … not quite sure that that’s actually responsible for the mutex lock/unlock calls.I've also now tried:
-
Compiling v12.16.1 locally (was using the binary from the website before)
-
Compiling master with gcc 9.2.1
-
Compiling master with
-march=native -
Removing calls to
GetBackingStore()where possible -
Reverting to
GetContents()in places
All changes made little to no difference.
-
@mscdex do you see similar results with any of the benchmarks from benchmark/buffers? Maybe some benchmark similar to your private code?
@mmarchini Yes, for example:
confidence improvement accuracy (*) (**) (***) buffers/buffer-tostring.js n=1000000 len=1024 args=0 encoding='utf8' *** -31.66 % ±0.42% ±0.55% ±0.72%Reacted by mary marchini, Anna Henningsen, Andrei Pechkurov and Jiawen GengThe
--prof-processoutput for thatbuffer-tostringbenchmark shows basically the same top results as I showed originally.If that helps, I can also see the same performance degradation on 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux, gcc 7.5.0:
$ node benchmark/compare.js --old ../node-v12.x/node --new ./node --filter buffer-tostring --runs 10 --set len=1024 --set encoding=utf8 buffers | Rscript benchmark/compare.R [00:00:25|% 100| 1/1 files | 20/20 runs | 3/3 configs]: Done confidence improvement accuracy (*) (**) (***) buffers/buffer-tostring.js n=1000000 len=1024 args=0 encoding='utf8' *** -34.37 % ±1.24% ±1.70% ±2.32% buffers/buffer-tostring.js n=1000000 len=1024 args=1 encoding='utf8' *** -31.29 % ±0.59% ±0.82% ±1.12% buffers/buffer-tostring.js n=1000000 len=1024 args=3 encoding='utf8' *** -32.47 % ±0.98% ±1.34% ±1.83%68 remaining items
Seems like the bug got fixed by now. Closing
- addedconfirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
on Sep 12, 2025 - added 2 commits that reference this issue
on Sep 12, 2025
Linux foo 5.0.0-36-generic #39~18.04.1-Ubuntu SMP Tue Nov 12 11:09:50 UTC 2019 x86_64 x86_64 x86_64 GNU/LinuxI was running some benchmarks (for private code) and noticed a significant slowdown with some Buffer methods. Here is a comparison of the C++ portion of
--profbetween v12.16.1 and master:v12.16.1:
Details
master:
Details
As you will see, master has these additional items at the top of the list:
Is there some way we can avoid this slowdown?