The node:bench module supports defining and running JavaScript benchmarks in\nthe current process, and running one benchmark file in a fresh child process.\nTo access it:
import { bench, suite } from 'node:bench';\nconst { bench, suite } = require('node:bench');\nThis module is only available under the node: scheme.
Save the following as benchmark.mjs:
import { bench, suite } from 'node:bench';\n\nsuite('URL', () => {\n const input = 'https://example.com/a?b=c';\n\n bench('construct', {\n samples: 30,\n params: { input: 'short' },\n }, (b) => {\n const operations = 10_000;\n let totalLength = 0;\n\n b.start();\n for (let i = 0; i < operations; i++) {\n totalLength += new URL(input).href.length;\n }\n b.end(operations);\n\n if (totalLength !== operations * input.length) {\n throw new Error('Unexpected URL result');\n }\n });\n});\nRun the benchmark from the command line:
\nnode --bench benchmark.mjs\nBenchmarks are executed serially in declaration order. Declared benchmarks are\nscheduled automatically. Call run() during the same turn as the declarations\nto consume the event stream or configure filtering.\nIf an automatically scheduled run fails and run() was not called, the process\nexit code is set to 1.
Each warmup and measured sample invokes the benchmark function once with a\nfresh {BenchContext}. The function must either call context.start() and\ncontext.end(operations) exactly once, or call context.record(sample) exactly\nonce to provide an externally measured sample. Setup before start() and\ncleanup after end() are outside the measured region. Promise-returning\nfunctions are awaited.
By default, an event loop turn occurs between sample invocations. An embedded\nrunner can disable this using yieldBetweenSamples. The runner executes\nbenchmarks serially, but it does not provide process isolation. Other work in\nthe process, JIT compilation, garbage collection, CPU frequency changes, and\nsystem load can all affect results. Keep raw samples when comparing results and\ninvestigate noisy or skewed distributions rather than treating a confidence\ninterval as a pass/fail threshold.
A statistically consistent result does not prove that a benchmark measured the\nintended work. An optimizing runtime can remove work whose result is unused or\nspecialize it more narrowly than the workload being modeled. Framework and loop\noverhead can also dominate operations that are too short. To reduce these risks:
\ncontext.start() and context.end(). If loop bookkeeping is material\nrelative to one operation, batch multiple operations per iteration and report\nthe total operation count.samples for trends that indicate insufficient warmup or\noptimization tiering, pauses consistent with garbage collection, and\nmultimodal distributions.node:bench does not force a particular optimization state or infer whether an\nengine eliminated work. Such controls and diagnostics are runtime-specific and\nheuristic, and do not replace validating the benchmark workload.
Calling context.done() during a measured sample completes the benchmark after\nthat sample. This allows a higher-level tool to treat samples as a maximum and\nimplement a dynamic sampling policy.
The number of operations can differ between samples. Summary statistics treat\neach sample's rate as one equally weighted observation. In particular,\nsummary.mean is the arithmetic mean of the per-sample rates. It is not the\npooled throughput calculated as:
1_000_000_000 * sum(sample.operations) / sum(sample.duration_ns)\nThe two values can differ when sample durations vary because pooled throughput\nweights each per-sample rate by its duration. A higher-level tool that varies\nbatch sizes should choose the aggregation that matches its analysis. It can\ncalculate pooled throughput from the raw samples; operation counts should be\nsummed as bigint values because their total can exceed\nNumber.MAX_SAFE_INTEGER even though each count cannot.
node:bench does not designate a benchmark as a baseline or produce a pass/fail\ncomparison between runs. It exposes raw samples, stable benchmark identities,\nparameters, and tags so that comparison policy can remain in higher-level\ntools. A tool can use benchId to match the same declaration and parameters\nacross compatible source layouts, and use a tag or its own metadata to identify\na baseline.
Comparison tools should retain the raw sample rates and verify that execution\nplans and relevant environment details are comparable. The appropriate analysis\ndepends on the experimental design and distribution. For example, independent\nsamples might use Welch's t-test or a rank-based test, while observations that\nwere deliberately paired require paired analysis. Tools should also consider\neffect sizes, uncertainty, and correction when testing multiple benchmarks.\nThe general-purpose <Histogram> statistics in node:perf_hooks can support such\nanalysis, but the runner does not select a method or significance threshold.
The module-level declaration functions use a shared runner and schedule it\nautomatically. Higher-level tools can create isolated, explicitly started\nrunners instead:
\nimport { createRunner } from 'node:bench';\n\nconst runner = createRunner({ yieldBetweenSamples: false });\n\nrunner.bench('example', { samples: 100 }, (b) => {\n const operations = chooseOperationCount();\n b.start();\n runOperations(operations);\n const sample = b.end(operations);\n\n if (hasEnoughData(sample)) b.done();\n});\n\nfor await (const record of runner.run()) {\n // Consume structured benchmark records.\n}\nEach runner has independent declarations, hooks, filtering, and output. Unlike\nthe module-level declarations, creating a benchmark on an explicit runner does\nnot schedule execution. This allows packages to collect declarations and start\nthem later. Calling the explicit runner's run() function prevents additional\ndeclarations and a second call to run() is an error.
The --bench flag runs one or more explicit benchmark files or glob patterns:
node --bench benchmark.mjs\nnode --bench --bench-reporter=json 'benchmarks/**/*.js'\nFiles are sorted and executed serially. The default\n--bench-isolation=process mode runs each file in a separate child process and\nemits one aggregate summary. Structured events are transferred to the parent\nwithout JSON conversion, preserving BigInt durations, errors, and parameter\nvalues. Child writes to stdout and stderr are emitted as diagnostic records so\nthey do not corrupt reporter output.
--bench-isolation=none imports all files into the runner process. This mode\nhas lower startup overhead, but module, heap, and process state carry between\nfiles, and user writes share stdout and stderr with reporters.
Worker-thread isolation is not a CLI mode. Each newly constructed <Worker> has a\nseparate V8 isolate, JavaScript heap, and event loop, typically with lower\nstartup cost than a child process. Reusing a worker preserves its module and heap\nstate. Workers also share libuv's process-wide thread pool and can share\nprocess-global native or addon state, so they do not provide the same boundary\nas process isolation.
Higher-level tools can experiment with worker isolation by loading benchmark\ncode inside a worker, measuring there, transferring structured sample data, and\npassing it to context.record(). The reported duration_ns can exclude\nmessage transport when the worker captures both timestamps. Tools should\nidentify worker modules and workloads explicitly. They should not stringify\narbitrary functions or closures to move them between isolates, because closures\ncannot be reconstructed with their original lexical environment.
Benchmark files passed to --bench should declare benchmarks but must not call\nrun(). The CLI supports --bench-name-pattern, --bench-samples,\n--bench-warmup, --bench-reporter, and --bench-reporter-destination. See\nthe command-line options documentation for details.
Preload modules passed through --require or --import should not declare\nbenchmarks. Such declarations are not associated with an entry file and have\nan entryFile value of null. Their fileRunId identifies the runner or child\nexecution in which they occurred. With process isolation, a preload is evaluated\nand its declarations run once for every benchmark child process.
The built-in reporters are available from the scheme-only\nnode:bench/reporters module:
import { json, spec } from 'node:bench/reporters';\nconst { json, spec } = require('node:bench/reporters');\nReporter values can be passed directly to stream.compose():
import { bench, run } from 'node:bench';\nimport { spec } from 'node:bench/reporters';\nimport process from 'node:process';\n\nbench('example', (b) => {\n b.start();\n doWork();\n b.end(1);\n});\n\nrun().compose(spec).pipe(process.stdout);\nThe spec reporter buffers results and outputs a concise table containing the\nsample count, mean rate, 95% confidence interval for the mean, median rate, and\nwarnings. A coefficient of variation above 5% is reported as noisy, and an\nabsolute skewness above 1 is reported as skewed. The exact human-readable\nformat is subject to change.
The json reporter emits every lifecycle record as newline-delimited JSON.\nBigInt values, including duration_ns, are encoded as decimal strings. Errors\nare represented using their name, message, stack, code, cause, and\nerrors properties. As required by JSON, non-finite numbers are encoded as\nnull.
Custom reporters use the same composition contract. They can be transforms or\nfunctions accepted by stream.compose(). The composed readable can be piped to\nany writable destination:
import { run } from 'node:bench';\nimport process from 'node:process';\n\nasync function* names(source) {\n for await (const { type, data } of source) {\n if (type === 'bench:complete') {\n yield `${data.name}\\n`;\n }\n }\n}\n\nrun().compose(names).pipe(process.stdout);\nEach measured sample has the following properties:
\noperations <number> The positive operation count passed to context.end() or context.record().duration_ns <bigint> The measured duration in nanoseconds.rate <number> Operations per second.detail <any> The optional cloned sample detail.A completed benchmark result contains:
\nrunId <string> The opaque logical run identity.fileRunId <string> The opaque file runner or child execution identity.entryFile <string> | <null> The top-level file that caused this declaration.benchId <string> The stable declaration identity within the same source\nlayout.parentId <string> | <null> The stable containing suite identity.name <string> The benchmark name.namePath <string>[] The hierarchical suite and benchmark names.file <string> The declaration source file.line <number> The source line.column <number> The source column.tags <string>[] The inherited canonical tags.params <Object> The canonical parameter metadata.samples <Object>[] The exact measured samples in measurement invocation\norder.summary <Object>\nmean <number> The equally weighted arithmetic mean of per-sample rates,\nnot pooled throughput across all operations and durations.median <number> The median per-sample rate.min <number> The minimum per-sample rate.max <number> The maximum per-sample rate.stddev <number> The population standard deviation of rates.coefficientOfVariation <number> stddev / mean.confidenceInterval <Object> The 95% Student's t confidence interval for\nthe mean rate, with lower and upper properties.medianConfidenceInterval <Object> The 95% nonparametric confidence\ninterval for the median rate, with lower and upper properties.skewness <number> The skewness of the scaled rate histogram.Creates an explicitly started benchmark runner. Declarations made through one\nrunner do not interact with declarations made through another runner or through\nthe module-level functions. Call the returned run() function to start the\nrunner and obtain its {BenchmarksStream}.
Each runner can be started once. Its run() function accepts the same options\nas the module-level run(). run({ yieldBetweenSamples }) overrides the\nvalue passed to createRunner().
Warmup invocations use the same callback and timing contract as measured\nsamples, but their samples are discarded. An exception, rejection, timeout,\nabort, missing timing call, or duplicate timing call stops the current\nbenchmark. Later benchmarks continue to run.
\nAfter a timeout or abort, the runner briefly waits for asynchronous benchmark\nwork to settle before continuing. If it remains pending, all later benchmarks\nthat were selected to run fail without running so that their measurements\ncannot overlap with that work.
\nFor each warmup and measured callback, the runner subscribes to the configured\ndiagnostics channels. Each publication queues a context diagnostic whose\nmessage is { name, message }, containing the string channel name and the\npublished message. Subscriptions are removed when the callback settles or is\naborted.
A timeout or abort cannot interrupt synchronous JavaScript and does not forcibly\ncancel asynchronous work that ignores context.signal.
The benchId is based on the declaration source file, hierarchical suite and\nbenchmark names, and canonicalized parameters. It is stable for repeated runs\nfrom the same source location, but the embedded source value is not normalized\nacross checkout roots, module formats, operating systems, or path casing.
Execution scope is represented separately. A runId identifies one logical\nrun, while fileRunId identifies a file runner or child execution within that\nrun. The entryFile field records which entry-file import caused a declaration\nand is null for declarations made by preload modules.\nThe same benchId can therefore occur under multiple fileRunId values when\nentry files use a shared declaration helper. Declaring the same benchId more\nthan once within one file execution scope reports an error rather than merging\nthe samples.
Shorthand for bench(name, { ...options, skip: true }, fn).
Shorthand for bench(name, { ...options, only: true }, fn).
Suite functions run while declarations are collected. Promise-returning suite\nfunctions are awaited before benchmark execution begins.
" }, { "textRaw": "`describe([name][, options], fn)`", "name": "describe", "type": "method", "meta": { "added": [ "REPLACEME" ], "changes": [] }, "signatures": [ { "params": [ { "name": "name", "optional": true }, { "name": "options", "optional": true }, { "name": "fn" } ] } ], "desc": "Alias for suite().
Registers a hook that runs once before the benchmarks in the current suite.
" }, { "textRaw": "`after(fn)`", "name": "after", "type": "method", "meta": { "added": [ "REPLACEME" ], "changes": [] }, "signatures": [ { "params": [ { "textRaw": "`fn` {Function|AsyncFunction} The hook function.", "name": "fn", "type": "Function|AsyncFunction", "desc": "The hook function." } ] } ], "desc": "Registers a hook that runs once after the benchmarks in the current suite.
" }, { "textRaw": "`beforeEach(fn)`", "name": "beforeEach", "type": "method", "meta": { "added": [ "REPLACEME" ], "changes": [] }, "signatures": [ { "params": [ { "textRaw": "`fn` {Function|AsyncFunction} The hook function. It receives an object with the benchmark's `name`, `params`, and `signal`.", "name": "fn", "type": "Function|AsyncFunction", "desc": "The hook function. It receives an object with the benchmark's `name`, `params`, and `signal`." } ] } ], "desc": "Registers a hook that runs once before each complete logical benchmark in the\ncurrent suite. It does not run before every sample. Per-sample setup belongs in\nthe benchmark function before context.start() or context.record().
Registers a hook that runs once after each complete logical benchmark in the\ncurrent suite. It does not run after every sample. Per-sample cleanup belongs\nin the benchmark function after context.end() or context.record().
Returns the object-mode event stream for the in-process benchmark run. Call\nrun() during the same turn in which benchmarks are declared, before automatic\nexecution begins. Calling run() is optional when the returned stream is not\nneeded. An explicit runner created by createRunner() does not run\nautomatically, so its run() function may be called later.
import { bench, run } from 'node:bench';\n\nbench('example', { samples: 3 }, (b) => {\n b.start();\n doWork();\n b.end(1);\n});\n\nfor await (const { type, data } of run()) {\n if (type === 'bench:complete' && data.error === undefined) {\n console.log(data.name, data.summary.mean);\n }\n}\nRuns exactly one benchmark module in a fresh child process and returns its\nobject-mode event stream. A relative path is resolved from the current working\ndirectory when runFile() is called. path is not interpreted as a glob.\nUnless the signal is aborted or the stream is destroyed before startup, every\ncall uses a new child. Input discovery, ordering, concurrency, retries, and\nmulti-file scheduling remain the caller's responsibility.
When the Permission Model is enabled, the caller must have file system read\naccess to path and permission to create child processes.
Records use advanced child process serialization, preserving supported\nstructured values such as bigint and errors. Child writes to stdout and stderr\nbecome 'bench:diagnostic' records. A permission failure, module loading error,\nabnormal child exit, or cancellation also emits an error diagnostic and produces\na terminal 'bench:summary' whose success property is false; these execution\nfailures do not error the stream. If module evaluation fails after declaring\nbenchmarks, those declarations still run before the unsuccessful summary.
env, effective inherited options, and an explicitly provided execArgv are\ncopied when runFile() is called. The runner removes NODE_OPTIONS, replaces\nIPC-related environment variables, and sets its private child-context, run\nidentity, and file identity variables, overriding properties with those names\nin env. Pass child Node.js options through execArgv, not NODE_OPTIONS.\nStandard child_process environment propagation still applies, including\nNODE_V8_COVERAGE, permission-model options, and required z/OS variables.\nAborting signal before the child starts produces an AbortError diagnostic\nwithout spawning it. Aborting during execution sends SIGTERM to the child and\nescalates to SIGKILL if it does not exit. Destroying the returned stream\nfollows the same termination procedure.
An instance of BenchContext is passed to every benchmark invocation. A new\ninstance is created for every warmup and measured sample.
The zero-based invocation index within the current context.phase. Warmup and\nmeasured samples have separate index sequences.
The benchmark name.
" }, { "textRaw": "{Object}", "name": "params", "type": "Object", "meta": { "added": [ "REPLACEME" ], "changes": [] }, "desc": "The benchmark's canonicalized parameter metadata.
" }, { "textRaw": "{string}", "name": "phase", "type": "string", "meta": { "added": [ "REPLACEME" ], "changes": [] }, "desc": "The current sample phase. It is 'warmup' for an unreported warmup invocation\nand 'measurement' for a measured invocation.
An abort signal that is triggered when the benchmark is aborted, times out, or\nfinishes.
" } ], "methods": [ { "textRaw": "`context.start()`", "name": "start", "type": "method", "meta": { "added": [ "REPLACEME" ], "changes": [] }, "signatures": [ { "params": [] } ], "desc": "Starts the measured region using process.hrtime.bigint(). Calling start()\nmore than once is an error.
Ends the measured region. The end timestamp is captured before operations is\nvalidated. Calling end() before start(), calling it more than once, or\nrecording a zero-duration sample is an error. When provided, detail is cloned\nafter the end timestamp is captured, so cloning time is outside the measured\nregion.
Records a measurement made by another clock or execution environment. This is\nuseful when a higher-level tool measures work in a worker and needs to exclude\nmessage transport from the duration. record() is mutually exclusive with\nstart() and end() within one callback and must be called exactly once.
Queues a diagnostic associated with the current benchmark, phase, and sample\nindex. Multiple diagnostics preserve call order. They are emitted after the\nsample callback settles and before that sample's 'bench:sample' event. Warmup\ndiagnostics are emitted even though warmup samples are not. Diagnostics queued\nbefore a callback failure are emitted before the failed 'bench:complete'\nevent and do not themselves cause the benchmark to fail. If a timeout or abort\nwins before the callback settles, queued diagnostics might not be emitted.
The message and detail are cloned synchronously. Options are also validated\nsynchronously. Calling diagnostic() between context.start() and\ncontext.end() therefore includes that work in the measured duration. Invalid\narguments or an uncloneable message or detail violate the sample contract.
Requests successful benchmark completion after the current measured sample.\nThe callback must still call either start() and end(), or record().\nCalling done() during a warmup invocation is an error. The configured\nsamples value remains the maximum number of measured invocations if done()\nis not called.
BenchmarksStream is an object-mode <stream.Readable>. Each lifecycle record is\nboth emitted as a named event and made available on the stream as { type, data }.
The events are emitted in execution order:
\n'bench:plan''bench:start''bench:sample''bench:complete''bench:diagnostic''bench:summary'Named event payloads, readable records, and benchmark completion values are\nindependent snapshots. Mutating a value received through one delivery mechanism\ndoes not change values received through the others. As with other\n<EventEmitter> events, multiple listeners for the same named event receive the\nsame event payload. Memory referenced through a <SharedArrayBuffer> remains\nshared, following structured clone semantics.
Once a consumer starts reading, the runner honors the stream's object-mode\nhigh-water mark and waits between records when the consumer is slower than the\nproducer. These waits occur after sample timing has ended, and records are not\ndropped. Snapshot creation and delivery waits are excluded from benchmark\ntimeout accounting. Before readable consumption starts, records accumulate in\nthe standard readable buffer and are included in readableLength. This keeps an\nunread stream and a consumer using only named events from deadlocking, but the\nbuffer can grow without bound. A named-event-only consumer that does not need\nreadable records should call stream.resume() to discard them. Destroying the\nstream stops readable delivery but does not cancel benchmark execution, so\nbenchmark completion promises still settle. Automatically scheduled\nmodule-level runs drain their stream internally.
With process isolation, each record sent by a child is acknowledged only after\nthe parent has accepted it. A child sends no additional record until it receives\nthat acknowledgement, bounding the IPC relay when a reporter is slow.
\nEvery benchmark-scoped event contains runId, fileRunId, entryFile,\nbenchId, parentId, and namePath. runId and fileRunId are opaque and\nchange between runs. entryFile identifies the top-level benchmark file whose\nloading caused the declaration, while file identifies the source location of\nthe declaration itself. parentId is based on the containing suite's source\nfile and hierarchical name path.
After asynchronous suite declarations settle, an in-process runner emits one\n'bench:plan' event for every benchmark it collected, in declaration order.\nAll plans from that runner are emitted before its suite hooks or benchmark\ncallbacks run. With process isolation, files run in separate children, so plans\nfor a later file are emitted after an earlier child has completed. With no\nisolation, all files share one runner and their plans are emitted before any\nbenchmark executes. Plan data contains the benchmark-scoped identity, location,\ntags, and parameters described in benchmark result, together with:
diagnosticChannels <string>[] The inherited string channel names\nsubscribed to during each callback.samples <number> The effective maximum number of measured callback\ninvocations after run-level overrides.warmup <number> The effective number of unreported warmup callback\ninvocations after run-level overrides.timeout <number> | <null> The timeout in milliseconds, or null when no timeout\nis configured.yieldBetweenSamples <boolean> Whether an event loop turn is scheduled between\nsample callbacks.selected <boolean> Whether the benchmark is eligible to run after applying skip, only, and namePattern selection. Execution can still be prevented\nby a duplicate declaration, suite build, hook, abort, or other runtime failure.skip <boolean> | <string> When selected is false, the explicit skip value or\nthe selection reason, such as 'only' or 'name pattern'.The plan contains execution settings known to the runner. Runtime version,\noperating system, processor, and other environment metadata are intentionally\nleft for reporters and higher-level tools to collect.
\n'bench:complete' data contains a benchmark result. A failed result has an\nadditional error property and may contain samples recorded before the error.\nA skipped result has an additional skip property and an empty samples\narray. 'bench:diagnostic' reports loading, suite, and hook errors as well as\npublic context diagnostics. A context diagnostic contains the benchmark-scoped\nidentity fields, phase, index, message, level, source location, and\noptional detail. 'bench:summary' contains overall runId, fileRunId,\nentryFile, success, counts, duration_ns, and file properties.\nfileRunId, entryFile, and file are <string> | <null>; they are null when the\nsummary aggregates multiple files.