child_process: improve spawn performance on Linux #48523

kvakil · 2023-06-22T17:25:21Z

deps: V8: cherry-pick 1a782f6543ae

Original commit message:

[base] add build flag to use MADV_DONTFORK

Embedders like Node.js and Electron expose fork(2)/execve(2) to their
users. Unfortunately when the V8 heap is very large, these APIs become
rather slow on Linux, due to the kernel needing to do all the
bookkeeping for the forked process (in clone's dup_mmap and execve's
exec_mmap). Of course, this is useless because the forked child thread
will never actually need to access the V8 heap.

Add a new build flag v8_enable_private_mapping_fork_optimization which
marks all pages allocated by OS::Allocate as MADV_DONTFORK. This
improves the performance of Node.js's fork/execve combination by 10x on
a 600 MB heap.

Fixed: v8:7381
Change-Id: Ib649f774d4a932b41886313ce89acc369923699d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4602858
Commit-Queue: Michael Lippautz <[email protected]>
Reviewed-by: Michael Lippautz <[email protected]>
Cr-Commit-Position: refs/heads/main@{#88447}

Refs: v8/v8@1a782f6

child_process: improve spawn performance on Linux

Speed up child_process.spawn by enabling the new V8 build flag which
makes fork/exec faster.

Here are the results of running the existing benchmark. Note that this
optimization helps more for applications with larger heaps, so this is
somewhat of an underestimate of the real world performance benefits.

$ ./node benchmark/compare.js --runs 15 \
        --new ./node \
        --old ~/node-v20/out/Release/node \
        --filter params child_process > cpr
$ node-benchmark-compare cpr
                                 confidence improvement  (***)
methodName='exec' n=1000                ***     60.84 % ±5.43%
methodName='execFile' n=1000            ***     53.72 % ±3.33%
methodName='execFileSync' n=1000        ***      9.10 % ±0.84%
methodName='execSync' n=1000            ***     10.44 % ±0.97%
methodName='spawn' n=1000               ***     53.10 % ±2.90%
methodName='spawnSync' n=1000           ***      8.64 % ±1.22%

  0.01 false positives, when considering a 0.1% risk acceptance (***)

Fixes: #25382
Fixes: #14917
Refs: nodejs/performance#93
Refs: nodejs/performance#89

Original commit message: [base] add build flag to use MADV_DONTFORK Embedders like Node.js and Electron expose fork(2)/execve(2) to their users. Unfortunately when the V8 heap is very large, these APIs become rather slow on Linux, due to the kernel needing to do all the bookkeeping for the forked process (in clone's dup_mmap and execve's exec_mmap). Of course, this is useless because the forked child thread will never actually need to access the V8 heap. Add a new build flag v8_enable_private_mapping_fork_optimization which marks all pages allocated by OS::Allocate as MADV_DONTFORK. This improves the performance of Node.js's fork/execve combination by 10x on a 600 MB heap. Fixed: v8:7381 Change-Id: Ib649f774d4a932b41886313ce89acc369923699d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4602858 Commit-Queue: Michael Lippautz <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/main@{#88447} Refs: v8/v8@1a782f6

nodejs-github-bot · 2023-06-22T17:25:26Z

Review requested:

@nodejs/gyp
@nodejs/v8-update

nodejs-github-bot · 2023-06-22T17:38:44Z

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-s390x,v8test=v8test/5405/

Speed up child_process.spawn by enabling the new V8 build flag which makes fork/exec faster. Here are the results of running the existing benchmark. Note that this optimization helps more for applications with larger heaps, so this is somewhat of an underestimate of the real world performance benefits. ```console $ ./node benchmark/compare.js --runs 15 \ --new ./node \ --old ~/node-v20/out/Release/node \ --filter params child_process > cpr $ node-benchmark-compare cpr confidence improvement (***) methodName='exec' n=1000 *** 60.84 % ±5.43% methodName='execFile' n=1000 *** 53.72 % ±3.33% methodName='execFileSync' n=1000 *** 9.10 % ±0.84% methodName='execSync' n=1000 *** 10.44 % ±0.97% methodName='spawn' n=1000 *** 53.10 % ±2.90% methodName='spawnSync' n=1000 *** 8.64 % ±1.22% 0.01 false positives, when considering a 0.1% risk acceptance (***) ``` Fixes: nodejs#25382 Fixes: nodejs#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89

nodejs-github-bot · 2023-06-22T17:40:52Z

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-ppc64le,v8test=v8test/5405/

nodejs-github-bot · 2023-06-22T18:00:14Z

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

nodejs-github-bot · 2023-06-22T18:00:41Z

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=benchmark-ubuntu2204-intel-64,v8test=v8test/5406/

nodejs-github-bot · 2023-06-22T18:03:34Z

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-s390x,v8test=v8test/5406/

nodejs-github-bot · 2023-06-22T18:05:00Z

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-ppc64le,v8test=v8test/5406/

nodejs-github-bot · 2023-06-22T20:47:16Z

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=benchmark-ubuntu2204-intel-64,v8test=v8test/5407/

nodejs-github-bot · 2023-06-22T20:48:30Z

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-s390x,v8test=v8test/5407/

nodejs-github-bot · 2023-06-22T20:49:05Z

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-ppc64le,v8test=v8test/5407/

nodejs-github-bot · 2023-06-22T20:53:35Z

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

nodejs-github-bot · 2023-06-22T22:18:28Z

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

nodejs-github-bot · 2023-06-23T00:07:35Z

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

Speed up child_process.spawn by enabling the new V8 build flag which makes fork/exec faster. Here are the results of running the existing benchmark. Note that this optimization helps more for applications with larger heaps, so this is somewhat of an underestimate of the real world performance benefits. ```console $ ./node benchmark/compare.js --runs 15 \ --new ./node \ --old ~/node-v20/out/Release/node \ --filter params child_process > cpr $ node-benchmark-compare cpr confidence improvement (***) methodName='exec' n=1000 *** 60.84 % ±5.43% methodName='execFile' n=1000 *** 53.72 % ±3.33% methodName='execFileSync' n=1000 *** 9.10 % ±0.84% methodName='execSync' n=1000 *** 10.44 % ±0.97% methodName='spawn' n=1000 *** 53.10 % ±2.90% methodName='spawnSync' n=1000 *** 8.64 % ±1.22% 0.01 false positives, when considering a 0.1% risk acceptance (***) ``` Fixes: nodejs#25382 Fixes: nodejs#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 PR-URL: nodejs#48523 Refs: v8/v8@1a782f6 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

Original commit message: [base] add build flag to use MADV_DONTFORK Embedders like Node.js and Electron expose fork(2)/execve(2) to their users. Unfortunately when the V8 heap is very large, these APIs become rather slow on Linux, due to the kernel needing to do all the bookkeeping for the forked process (in clone's dup_mmap and execve's exec_mmap). Of course, this is useless because the forked child thread will never actually need to access the V8 heap. Add a new build flag v8_enable_private_mapping_fork_optimization which marks all pages allocated by OS::Allocate as MADV_DONTFORK. This improves the performance of Node.js's fork/execve combination by 10x on a 600 MB heap. Fixed: v8:7381 Change-Id: Ib649f774d4a932b41886313ce89acc369923699d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4602858 Commit-Queue: Michael Lippautz <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/main@{#88447} Refs: v8/v8@1a782f6 PR-URL: nodejs#48523 Fixes: nodejs#25382 Fixes: nodejs#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

Speed up child_process.spawn by enabling the new V8 build flag which makes fork/exec faster. Here are the results of running the existing benchmark. Note that this optimization helps more for applications with larger heaps, so this is somewhat of an underestimate of the real world performance benefits. ```console $ ./node benchmark/compare.js --runs 15 \ --new ./node \ --old ~/node-v20/out/Release/node \ --filter params child_process > cpr $ node-benchmark-compare cpr confidence improvement (***) methodName='exec' n=1000 *** 60.84 % ±5.43% methodName='execFile' n=1000 *** 53.72 % ±3.33% methodName='execFileSync' n=1000 *** 9.10 % ±0.84% methodName='execSync' n=1000 *** 10.44 % ±0.97% methodName='spawn' n=1000 *** 53.10 % ±2.90% methodName='spawnSync' n=1000 *** 8.64 % ±1.22% 0.01 false positives, when considering a 0.1% risk acceptance (***) ``` Fixes: nodejs#25382 Fixes: nodejs#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 PR-URL: nodejs#48523 Refs: v8/v8@1a782f6 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

ruyadorno · 2023-09-10T03:38:08Z

This commit does not land cleanly on v18.x-staging and will need manual backport in case we want it in v18.

Original commit message: [base] add build flag to use MADV_DONTFORK Embedders like Node.js and Electron expose fork(2)/execve(2) to their users. Unfortunately when the V8 heap is very large, these APIs become rather slow on Linux, due to the kernel needing to do all the bookkeeping for the forked process (in clone's dup_mmap and execve's exec_mmap). Of course, this is useless because the forked child thread will never actually need to access the V8 heap. Add a new build flag v8_enable_private_mapping_fork_optimization which marks all pages allocated by OS::Allocate as MADV_DONTFORK. This improves the performance of Node.js's fork/execve combination by 10x on a 600 MB heap. Fixed: v8:7381 Change-Id: Ib649f774d4a932b41886313ce89acc369923699d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4602858 Commit-Queue: Michael Lippautz <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/main@{#88447} Refs: v8/v8@1a782f6 PR-URL: nodejs#48523 Fixes: nodejs#25382 Fixes: nodejs#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

Speed up child_process.spawn by enabling the new V8 build flag which makes fork/exec faster. Here are the results of running the existing benchmark. Note that this optimization helps more for applications with larger heaps, so this is somewhat of an underestimate of the real world performance benefits. ```console $ ./node benchmark/compare.js --runs 15 \ --new ./node \ --old ~/node-v20/out/Release/node \ --filter params child_process > cpr $ node-benchmark-compare cpr confidence improvement (***) methodName='exec' n=1000 *** 60.84 % ±5.43% methodName='execFile' n=1000 *** 53.72 % ±3.33% methodName='execFileSync' n=1000 *** 9.10 % ±0.84% methodName='execSync' n=1000 *** 10.44 % ±0.97% methodName='spawn' n=1000 *** 53.10 % ±2.90% methodName='spawnSync' n=1000 *** 8.64 % ±1.22% 0.01 false positives, when considering a 0.1% risk acceptance (***) ``` Fixes: nodejs#25382 Fixes: nodejs#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 PR-URL: nodejs#48523 Refs: v8/v8@1a782f6 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

Original commit message: [base] add build flag to use MADV_DONTFORK Embedders like Node.js and Electron expose fork(2)/execve(2) to their users. Unfortunately when the V8 heap is very large, these APIs become rather slow on Linux, due to the kernel needing to do all the bookkeeping for the forked process (in clone's dup_mmap and execve's exec_mmap). Of course, this is useless because the forked child thread will never actually need to access the V8 heap. Add a new build flag v8_enable_private_mapping_fork_optimization which marks all pages allocated by OS::Allocate as MADV_DONTFORK. This improves the performance of Node.js's fork/execve combination by 10x on a 600 MB heap. Fixed: v8:7381 Change-Id: Ib649f774d4a932b41886313ce89acc369923699d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4602858 Commit-Queue: Michael Lippautz <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/main@{#88447} Refs: v8/v8@1a782f6 PR-URL: #48523 Backport-PR-URL: #50098 Fixes: #25382 Fixes: #14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

Speed up child_process.spawn by enabling the new V8 build flag which makes fork/exec faster. Here are the results of running the existing benchmark. Note that this optimization helps more for applications with larger heaps, so this is somewhat of an underestimate of the real world performance benefits. ```console $ ./node benchmark/compare.js --runs 15 \ --new ./node \ --old ~/node-v20/out/Release/node \ --filter params child_process > cpr $ node-benchmark-compare cpr confidence improvement (***) methodName='exec' n=1000 *** 60.84 % ±5.43% methodName='execFile' n=1000 *** 53.72 % ±3.33% methodName='execFileSync' n=1000 *** 9.10 % ±0.84% methodName='execSync' n=1000 *** 10.44 % ±0.97% methodName='spawn' n=1000 *** 53.10 % ±2.90% methodName='spawnSync' n=1000 *** 8.64 % ±1.22% 0.01 false positives, when considering a 0.1% risk acceptance (***) ``` Fixes: #25382 Fixes: #14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 PR-URL: #48523 Backport-PR-URL: #50098 Refs: v8/v8@1a782f6 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

The linked v8 issue is closed. The NodeJS half of that issue has also been resolved. While there still may be issues related to child_process spawn performance, they are not related to this v8 issue. Refs: https://bugs.chromium.org/p/v8/issues/detail?id=7381 Refs: nodejs#48523 Refs: nodejs/performance#138

The linked v8 issue is closed. The NodeJS half of that issue has also been resolved. While there still may be issues related to child_process spawn performance, they are not related to this v8 issue. Refs: https://bugs.chromium.org/p/v8/issues/detail?id=7381 Refs: #48523 Refs: nodejs/performance#138 PR-URL: #51467 Reviewed-By: Keyhan Vakil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

The linked v8 issue is closed. The NodeJS half of that issue has also been resolved. While there still may be issues related to child_process spawn performance, they are not related to this v8 issue. Refs: https://bugs.chromium.org/p/v8/issues/detail?id=7381 Refs: nodejs#48523 Refs: nodejs/performance#138 PR-URL: nodejs#51467 Reviewed-By: Keyhan Vakil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

The linked v8 issue is closed. The NodeJS half of that issue has also been resolved. While there still may be issues related to child_process spawn performance, they are not related to this v8 issue. Refs: https://bugs.chromium.org/p/v8/issues/detail?id=7381 Refs: #48523 Refs: nodejs/performance#138 PR-URL: #51467 Reviewed-By: Keyhan Vakil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

The linked v8 issue is closed. The NodeJS half of that issue has also been resolved. While there still may be issues related to child_process spawn performance, they are not related to this v8 issue. Refs: https://bugs.chromium.org/p/v8/issues/detail?id=7381 Refs: nodejs#48523 Refs: nodejs/performance#138 PR-URL: nodejs#51467 Reviewed-By: Keyhan Vakil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

The linked v8 issue is closed. The NodeJS half of that issue has also been resolved. While there still may be issues related to child_process spawn performance, they are not related to this v8 issue. Refs: https://bugs.chromium.org/p/v8/issues/detail?id=7381 Refs: #48523 Refs: nodejs/performance#138 PR-URL: #51467 Reviewed-By: Keyhan Vakil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

Original commit message: [base] add build flag to use MADV_DONTFORK Embedders like Node.js and Electron expose fork(2)/execve(2) to their users. Unfortunately when the V8 heap is very large, these APIs become rather slow on Linux, due to the kernel needing to do all the bookkeeping for the forked process (in clone's dup_mmap and execve's exec_mmap). Of course, this is useless because the forked child thread will never actually need to access the V8 heap. Add a new build flag v8_enable_private_mapping_fork_optimization which marks all pages allocated by OS::Allocate as MADV_DONTFORK. This improves the performance of Node.js's fork/execve combination by 10x on a 600 MB heap. Fixed: v8:7381 Change-Id: Ib649f774d4a932b41886313ce89acc369923699d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4602858 Commit-Queue: Michael Lippautz <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/main@{#88447} Refs: v8/v8@1a782f6 PR-URL: nodejs/node#48523 Backport-PR-URL: nodejs/node#50098 Fixes: nodejs/node#25382 Fixes: nodejs/node#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

Speed up child_process.spawn by enabling the new V8 build flag which makes fork/exec faster. Here are the results of running the existing benchmark. Note that this optimization helps more for applications with larger heaps, so this is somewhat of an underestimate of the real world performance benefits. ```console $ ./node benchmark/compare.js --runs 15 \ --new ./node \ --old ~/node-v20/out/Release/node \ --filter params child_process > cpr $ node-benchmark-compare cpr confidence improvement (***) methodName='exec' n=1000 *** 60.84 % ±5.43% methodName='execFile' n=1000 *** 53.72 % ±3.33% methodName='execFileSync' n=1000 *** 9.10 % ±0.84% methodName='execSync' n=1000 *** 10.44 % ±0.97% methodName='spawn' n=1000 *** 53.10 % ±2.90% methodName='spawnSync' n=1000 *** 8.64 % ±1.22% 0.01 false positives, when considering a 0.1% risk acceptance (***) ``` Fixes: nodejs/node#25382 Fixes: nodejs/node#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 PR-URL: nodejs/node#48523 Backport-PR-URL: nodejs/node#50098 Refs: v8/v8@1a782f6 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

Original commit message: [base] add build flag to use MADV_DONTFORK Embedders like Node.js and Electron expose fork(2)/execve(2) to their users. Unfortunately when the V8 heap is very large, these APIs become rather slow on Linux, due to the kernel needing to do all the bookkeeping for the forked process (in clone's dup_mmap and execve's exec_mmap). Of course, this is useless because the forked child thread will never actually need to access the V8 heap. Add a new build flag v8_enable_private_mapping_fork_optimization which marks all pages allocated by OS::Allocate as MADV_DONTFORK. This improves the performance of Node.js's fork/execve combination by 10x on a 600 MB heap. Fixed: v8:7381 Change-Id: Ib649f774d4a932b41886313ce89acc369923699d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4602858 Commit-Queue: Michael Lippautz <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/main@{#88447} Refs: v8/v8@1a782f6 PR-URL: nodejs/node#48523 Backport-PR-URL: nodejs/node#50098 Fixes: nodejs/node#25382 Fixes: nodejs/node#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

Speed up child_process.spawn by enabling the new V8 build flag which makes fork/exec faster. Here are the results of running the existing benchmark. Note that this optimization helps more for applications with larger heaps, so this is somewhat of an underestimate of the real world performance benefits. ```console $ ./node benchmark/compare.js --runs 15 \ --new ./node \ --old ~/node-v20/out/Release/node \ --filter params child_process > cpr $ node-benchmark-compare cpr confidence improvement (***) methodName='exec' n=1000 *** 60.84 % ±5.43% methodName='execFile' n=1000 *** 53.72 % ±3.33% methodName='execFileSync' n=1000 *** 9.10 % ±0.84% methodName='execSync' n=1000 *** 10.44 % ±0.97% methodName='spawn' n=1000 *** 53.10 % ±2.90% methodName='spawnSync' n=1000 *** 8.64 % ±1.22% 0.01 false positives, when considering a 0.1% risk acceptance (***) ``` Fixes: nodejs/node#25382 Fixes: nodejs/node#14917 Refs: nodejs/performance#93 Refs: nodejs/performance#89 PR-URL: nodejs/node#48523 Backport-PR-URL: nodejs/node#50098 Refs: v8/v8@1a782f6 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>

kvakil added child_process Issues and PRs related to the child_process subsystem. v8 engine Issues and PRs related to the V8 dependency. performance Issues and PRs related to the performance of Node.js. labels Jun 22, 2023

nodejs-github-bot added build Issues and PRs related to build files or the CI. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jun 22, 2023

kvakil added the request-ci Add this label to start a Jenkins CI on a PR. label Jun 22, 2023

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jun 22, 2023

This comment was marked as outdated.

Sign in to view

kvakil force-pushed the speed-spawn-bp branch from 99a96e0 to 65c31d7 Compare June 22, 2023 17:40

kvakil added the request-ci Add this label to start a Jenkins CI on a PR. label Jun 22, 2023

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jun 22, 2023

github-actions bot mentioned this pull request Jun 23, 2023

CI Reliability 2023-06-23 nodejs/reliability#596

Open

30 tasks

kvakil added the review wanted PRs that need reviews. label Jun 23, 2023

ruyadorno added the backport-requested-v18.x PRs awaiting manual backport to the v18.x-staging branch. label Sep 10, 2023

aduh95 mentioned this pull request Oct 9, 2023

[v18.x backport] child_process: improve spawn performance on Linux #50098

Closed

aduh95 added backport-open-v18.x Indicate that the PR has an open backport. and removed backport-requested-v18.x PRs awaiting manual backport to the v18.x-staging branch. labels Oct 9, 2023

targos added backported-to-v18.x PRs backported to the v18.x-staging branch. and removed backport-open-v18.x Indicate that the PR has an open backport. labels Nov 26, 2023

targos mentioned this pull request Nov 28, 2023

v18.19.0 release proposal #50953

Merged

isker mentioned this pull request Jan 15, 2024

doc: remove reference to resolved child_process v8 issue #51467

Merged

GulajavaMinistudio mentioned this pull request Jan 19, 2024

Create a new pull request by comparing changes across two branches javascript-indonesias/node#959

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

child_process: improve spawn performance on Linux #48523

child_process: improve spawn performance on Linux #48523

kvakil commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

This comment was marked as outdated.

This comment was marked as outdated.

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 23, 2023

ruyadorno commented Sep 10, 2023

child_process: improve spawn performance on Linux #48523

child_process: improve spawn performance on Linux #48523

Conversation

kvakil commented Jun 22, 2023

deps: V8: cherry-pick 1a782f6543ae

child_process: improve spawn performance on Linux

nodejs-github-bot commented Jun 22, 2023

This comment was marked as outdated.

This comment was marked as outdated.

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 22, 2023

nodejs-github-bot commented Jun 23, 2023

ruyadorno commented Sep 10, 2023