Possible external-memory / GC regression from v22 to v24 in short-lived Readable chunk workloads
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 48/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- javascript, node.js
- 領域
- backend, performance
研究方向
首先,使用 benchmark/compare.js 針對兩個 Node.js 版本執行 benchmark/streams/readable-push-buffer-burst-minimal.js,然後比較附加的火焰圖。調查 GC 行為的變化以及 --external-memory-accounted-in-global-limit 的影響。完成的標準是確定 v22 到 v24 的效能差異是預期的變更還是回歸,並提供來自可重現 benchmark 結果的證據。
由索引模型根據 Issue 內容生成。
描述
I’m seeing a pretty consistent regression from Node.js v22.22.3 to v24.16.0 on a small stream benchmark that creates lots of short-lived Readables and drains them immediately. The code in the benchmark file benchmark/streams/readable-push-buffer-burst-minimal.js is not optimal, but that's not the point as it demonstrates the issue.
'use strict';
const common = require('../common.js');
const assert = require('assert');
const { Readable } = require('stream');
const bench = common.createBenchmark(main, {
n: [2e4],
bodySize: [120 * 1024],
});
function repeat(size, ch) {
return ch.repeat(size);
}
function makeBurstChunks(bodySize) {
return [
'<!doctype html><html><head><title>burst</title><style>',
repeat(1024, 'a'),
'</style></head><body><header>',
repeat(2048, 'b'),
'</header><main>',
repeat(bodySize, 'c'),
'</main><script>',
repeat(2048, 'd'),
'</script></body></html>',
];
}
function toBuffers(chunks) {
return chunks.map((chunk) => Buffer.from(chunk, 'utf8'));
}
function buildAndDrain(buffersIn) {
const buffersOut = [];
for (let i = 0; i < buffersIn.length; i++) {
const readable = new Readable({ read() {} });
readable.push(buffersIn[i]);
readable.push(null);
let chunk;
while ((chunk = readable.read()) !== null)
buffersOut.push(chunk);
}
return Buffer.concat(buffersOut);
}
function main({ n, bodySize }) {
const inputBuffers = toBuffers(makeBurstChunks(bodySize));
const expectedLength = inputBuffers.reduce(
(sum, chunk) => sum + chunk.length,
0,
);
const warmup = buildAndDrain(inputBuffers);
assert.strictEqual(warmup.length, expectedLength);
bench.start();
for (let i = 0; i < n; ++i) {
const buffer = buildAndDrain(inputBuffers);
if (buffer.length !== expectedLength)
throw new Error(`Unexpected buffer length: ${buffer.length}`);
}
bench.end(n);
}
So running the benchmark comparing v22.22.3 vs v24.16.0, I see the following results:
$ node benchmark/compare.js --old ~/.nvm/versions/node/v22.22.3/bin/node --new ~/.nvm/versions/node/v24.16.0/bin/node --filter readable-push-buffer-burst-minimal streams > readable-push-buffer-burst-minimal.csv
[00:00:58|% 100| 1/1 files | 60/60 runs | 1/1 configs]: Done
$ npx node-benchmark-compare readable-push-buffer-burst-minimal.csv
confidence improvement accuracy (*) (**) (***)
streams/readable-push-buffer-burst-minimal.js bodySize=122880 n=20000 *** -37.18 % ±4.12% ±5.55% ±7.36%
I also profiled both cases with perf and generated flamegraphs. The main difference seems to be GC behavior: v22 is mostly dominated by scavenges, while v24 is much more major-GC-heavy. See attached flamegraph-22.svg and flamegraph-24.svg.
One more datapoint that seems relevant: if I run v24 with --external-memory-accounted-in-global-limit, the regression drops a lot. Here are the results using a patched benchmark/compare.js that supports per-binary flags:
$ node benchmark/compare.js --old ~/.nvm/versions/node/v22.22.3/bin/node --new ~/.nvm/versions/node/v24.16.0/bin/node --new-flags "--external-memory-accounted-in-global-limit" --filter readable-push-buffer-burst-minimal streams > readable-push-buffer-burst-minimal_with_flag.csv
[00:00:50|% 100| 1/1 files | 60/60 runs | 1/1 configs]: Done
$ npx node-benchmark-compare readable-push-buffer-burst-minimal_with_flag.csv
confidence improvement accuracy (*) (**) (***)
streams/readable-push-buffer-burst-minimal.js bodySize=122880 n=20000 *** -11.18 % ±4.28% ±5.76% ±7.62%
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 (***)
So in summary, when running the benchmark, I see a 37% regression which drops to only 11% when using v24 with the --external-memory-accounted-in-global-limit flag.
Does this ring a bell as a known regression or is this to be expected in v24?
Flamegraphs
- flamegraph-22.svg (
v22.22.3) - flamegraph-24.svg (
v24.16.0) - flamegraph-24-flag.svg (
v24.16.0 --external-memory-accounted-in-global-limit)
/cc @RafaelGSS
- 主要語言
- JavaScript
- 星號
- 122k
- 分支
- 37.4k
- 平均合併
- 4 天 2 小時
- 30 天內合併 PR
- 277
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
nodejs/node 的其他 Issue
-
doc
難度 2/5 1-3 小時 新手友好度 65/100
-
build
難度 1/5 1 小時以內 新手友好度 88/100
-
難度 2/5 1-3 小時 新手友好度 84/100
-
難度 1/5 1 小時以內 新手友好度 90/100
-
feature request
難度 2/5 1-3 小時 新手友好度 68/100
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 65/100
antfu-collective/icones#398 ·
-
ECmail.com 未關閉
難度 1/5 1 小時以內 新手友好度 90/100
wesbos/burner-email-providers#554 ·
-
難度 2/5 1-3 小時 新手友好度 65/100
radiantearth/stac-browser#1023 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
-
難度 2/5 1-3 小時 新手友好度 75/100
components-web-app/docs#92 ·