Files
node/benchmark
Philipp Dunkel df2ea49e00 zlib: add crc32c
Add zlib.crc32c(data[, value]), which computes the CRC-32C checksum
(Castagnoli polynomial, RFC 3720 section 12.1). CRC-32C has better
error detection properties than the CRC-32 of zlib.crc32() and is the
checksum required by many current protocols, formats and services,
among them:

- iSCSI header and data digests (RFC 7143)
- SCTP packet checksums (RFC 9260)
- iWARP MPA framing (RFC 5044)
- NVMe/TCP header and data digests
- ext4, Btrfs and XFS metadata checksums
- the Snappy framing format
- Apache Kafka record batches
- LevelDB and RocksDB block checksums
- TensorFlow TFRecord files
- Google Cloud Storage and Amazon S3 object checksums

Implementing any of these in JavaScript currently needs a userland
CRC-32C, which is far slower than native code.

The function mirrors zlib.crc32(): it accepts a string (encoded as
UTF-8) or an ArrayBufferView, takes an optional 32-bit unsigned
starting value so a checksum can be continued across chunks, and has a
V8 fast API path.

The checksum is computed by absl::ExtendCrc32c() from the bundled
Abseil, which is already built and linked into node, so this adds no
new dependency and no new checksum implementation. absl_crc32c is
added to the libraries linked with --shared-abseil.

Abseil selects its hardware-accelerated CRC-32C path (SSE4.2 and
PCLMULQDQ on x64, the CRC32 and PMULL extensions on arm64) at compile
time, so with node's default compiler flags the portable table-driven
implementation is used. It runs at about the same speed as zlib.crc32()
(about 6.5 GB/s on a recent x64 machine), while the hardware path
reaches about 38 GB/s. Builds whose target CPU baseline already
includes those instructions get the hardware path without changes.
Enabling it for generic builds is left out on purpose: on x64, Abseil
uses the accelerated code for unrecognized CPUs without a runtime
feature check, so compiling it in unconditionally would fault on CPUs
without SSE4.2.

Signed-off-by: Philipp Dunkel <pip@pipobscure.com>
PR-URL: https://github.com/nodejs/node/pull/66828
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
2026-10-20 12:33:08 +00:00
..
2023-01-29 19:13:35 +01:00
2026-10-15 00:52:34 +00:00
2026-10-10 13:02:45 +00:00
2023-01-29 19:13:35 +01:00
2026-10-05 05:47:29 +00:00
2024-09-11 14:46:30 +00:00
2026-10-19 14:53:43 +00:00
2026-08-17 10:17:55 -07:00
2023-01-29 19:13:35 +01:00
2026-10-20 12:33:08 +00:00
2025-07-24 17:17:52 +00:00
2023-06-28 13:07:19 +00:00
2021-04-12 14:28:46 -07:00

Node.js Core Benchmarks

This folder contains code and data used to measure performance of different Node.js implementations and different ways of writing JavaScript run by the built-in JavaScript engine.

For a detailed guide on how to write and run benchmarks in this directory, see the guide on benchmarks.

Table of Contents

File tree structure

Directories

Benchmarks testing the performance of a single node submodule are placed into a directory with the corresponding name, so that they can be executed by submodule or individually. Benchmarks that span multiple submodules may either be placed into the misc directory or into a directory named after the feature they benchmark. E.g. benchmarks for various new ECMAScript features and their pre-ES2015 counterparts are placed in a directory named es. Fixtures that are not specific to a certain benchmark but can be reused throughout the benchmark suite should be placed in the fixtures directory.

Other Top-level files

The top-level files include common dependencies of the benchmarks and the tools for launching benchmarks and visualizing their output. The actual benchmark scripts should be placed in their corresponding directories.

  • _benchmark_progress.js: implements the progress bar displayed when running compare.js and scatter.js
  • _cli.js: parses the command line arguments passed to compare.js, run.js and scatter.js
  • _cli.R: parses the command line arguments passed to compare.R
  • _http-benchmarkers.js: selects and runs external tools for benchmarking the http subsystem.
  • bar.R: R script for visualizing the output of benchmarks with bar plots.
  • common.js: see Common API.
  • compare.js: command line tool for comparing performance between different Node.js binaries.
  • compare-node-bench.js: parallel comparison tool for explicit node:bench files. It does not change or invoke compare.js.
  • compare.R: R script for statistically analyzing the output of compare.js
  • run.js: command line tool for running individual benchmark suite(s).
  • scatter.js: command line tool for comparing the performance between different parameters in benchmark configurations, for example to analyze the time complexity. Pass --analyze to summarize the results without R.
  • scatter-node-bench.js: parallel scatter-data tool for an explicit node:bench file. It does not change or invoke scatter.js.
  • scatter.R: R script for visualizing the output of scatter.js with scatter plots.

node:bench evaluation tools

The compare-node-bench.js and scatter-node-bench.js tools run explicit node:bench files without changing the existing benchmark framework or its tools. Each repeated observation for a benchmark identity is collected by a separate process invocation with one measured sample. Benchmarks declared in the same file still execute serially in that process and can share JIT, garbage collector, heap, and cache state. This differs from legacy configuration-level process isolation and must be considered when comparing the frameworks.

Compare two binaries and analyze the compatible CSV using compare.R:

./node benchmark/compare-node-bench.js \
  --old ./node-main --new ./node-pr --runs 30 -- \
  benchmark/crypto/_create-hash.node-bench.js > compare-node-bench.csv
Rscript benchmark/compare.R < compare-node-bench.csv

Pass --analyze to run the same Welch analysis inline. --max-regression N implies --analyze and makes the command fail only when the Holm-Bonferroni adjusted one-sided p-value against the N% threshold is below 0.05 and the full 95% confidence interval is worse than -N%. Requiring both conditions prevents a noisy point estimate from failing a regression gate.

./node benchmark/compare-node-bench.js \
  --old ./node-main --new ./node-pr --runs 30 \
  --max-regression 5 -- benchmark/crypto/_create-hash.node-bench.js

Collect parameter data for the parallel buffer benchmark and plot it using scatter.R:

./node benchmark/scatter-node-bench.js --node ./node --runs 30 -- \
  benchmark/buffers/_buffer-compare-offset.node-bench.js \
  > scatter-node-bench.csv
Rscript benchmark/scatter.R --xaxis size --category method \
  --plot scatter-node-bench.png < scatter-node-bench.csv

Pass --analyze with an x-axis parameter to summarize the samples without R. The output includes mean and median confidence intervals, skew warnings, an optional bar chart, and Mann-Whitney U and Cliff's delta comparisons between consecutive x-axis values. Use --category for a second grouping parameter and --no-chart to omit the chart.

Because configurations in one file share a process, inline analysis averages aggregated configurations into one value per outer process. Consecutive x-axis comparisons use alternating, disjoint process sets so the unpaired Mann-Whitney test does not treat correlated values as independent samples.

./node benchmark/scatter-node-bench.js --runs 30 --analyze \
  --xaxis size --category method -- \
  benchmark/buffers/_buffer-compare-offset.node-bench.js

A file passed to scatter-node-bench.js must use one logical benchmark name. Parameter values distinguish its configurations. The tool rejects unstable identities and names or parameters that would merge unrelated CSV groups.

The underscore-prefixed benchmark files are parallel ports used to compare the measurement frameworks. Legacy discovery ignores them, so the original files remain the source benchmarks for run.js, compare.js, and scatter.js. The ports use the platform-specific original relative filename as their benchmark name and preserve parameter column names to keep CSV grouping compatible. For a direct framework comparison, collect the same number of runs from an original benchmark with scatter.js and from its port with scatter-node-bench.js, then compare their rate distributions.

Common API

The common.js module is used by benchmarks for consistency across repeated tasks. It has a number of helpful functions and properties to help with writing benchmarks.

createBenchmark(fn, configs[, options])

See the guide on writing benchmarks.

default_http_benchmarker

The default benchmarker used to run HTTP benchmarks. See the guide on writing HTTP benchmarks.

PORT

The default port used to run HTTP benchmarks. See the guide on writing HTTP benchmarks.

sendResult(data)

Used in special benchmarks that can't use createBenchmark and the object it returns to accomplish what they need. This function reports timing data to the parent process (usually created by running compare.js, run.js or scatter.js).