Skip to content

Instantly share code, notes, and snippets.

@ast-hugger

ast-hugger/JetStream3-overview.md

Last active February 25, 2026 16:57
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save ast-hugger/defdafd205c856b3062bde4225a2f1e3 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save ast-hugger/defdafd205c856b3062bde4225a2f1e3 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
JetStream3-overview.md

JetStream 3 Benchmarks

Table of Contents

Overview

JetStream 3 is a JavaScript and WebAssembly benchmark suite. It can be run in a browser or from a JavaScript shell command line using cli.js. The suite consists of independently registered benchmarks, each defined as a subclass of Benchmark. The driver (JetStreamDriver.js) loads each benchmark's source files and preloaded resources, constructs a Benchmark instance, and runs it through a series of timed iterations.

Iterations and timing

Each benchmark runs a configurable number of iterations (default: 120). The driver times every iteration individually using performance.now(), clamping each measurement to a minimum of 1 ms. Some benchmarks override the default iteration count — for example, typescript-lib runs only 1 iteration, while most others use the default 120. The iteration count can also be overridden globally or per-benchmark from the command line using --iteration-count.

Before each iteration, the driver optionally calls prepareForNextIteration() on the benchmark instance (used for example by the code-load benchmarks to prepare fresh source text). If the --force-gc flag is set, a garbage collection is triggered before each benchmark (but not between iterations).

Score calculation

An individual iteration's time in milliseconds is converted to a score using the formula:

score = 5000 / time_ms

Higher scores indicate faster execution. A 5 ms iteration produces a score of 1000; a 50 ms iteration produces a score of 100.

Most benchmarks (those using DefaultBenchmark or AsyncBenchmark) produce up to three sub-scores from the iteration times:

  • First: The score of the very first iteration, reported separately because it typically includes one-time costs such as JIT compilation, inline cache population, and lazy initialization.
  • Worst: The remaining iterations (all except the first) are sorted slowest-to-fastest. The N slowest are averaged, and that average time is converted to a score. N is the benchmark's worstCaseCount (default: 4, but varies per benchmark from 0 to 16). This sub-score captures worst-case behavior such as garbage collection pauses or JIT recompilation.
  • Average: The arithmetic mean of all remaining iteration times (after removing the first iteration), converted to a score. This represents steady-state performance.

If a benchmark has only 1 iteration, only the First sub-score is reported. If worstCaseCount is 0, the Worst sub-score is omitted.

The benchmark's overall score is the geometric mean of its sub-scores. For a benchmark with First, Worst, and Average sub-scores, that is:

benchmark_score = (First × Worst × Average) ^ (1/3)

Overall suite score

The suite's overall score is the geometric mean of all individual benchmark scores:

overall_score = (score_1 × score_2 × ... × score_N) ^ (1/N)

This means each benchmark contributes equally to the overall score in relative terms, regardless of its absolute magnitude. A 10% improvement in any single benchmark has the same proportional effect on the overall score.

Grouped benchmarks

Some benchmarks are grouped under a single name — for example, the SunSpider and WTB (Web Tooling Benchmark) entries each contain multiple sub-benchmarks. A grouped benchmark runs each of its sub-benchmarks sequentially, then reports a single score that is the geometric mean of the sub-benchmarks' corresponding sub-scores. From the perspective of the overall suite score, a grouped benchmark counts as one entry.

Significance of results

JetStream 3 does not include a built-in statistical significance test for comparing results across runs. The suite produces a single score per run. To determine whether a score difference between two engine builds is statistically significant, an external harness (such as WebKit's run-benchmark tool) must run the suite multiple times and apply a statistical test — typically Welch's t-test on the resulting score distributions. A difference is generally considered significant if the p-value is below 0.05 (95% confidence). Without multiple runs and a proper statistical comparison, small score differences should not be treated as meaningful.

8bitbench-wasm

Emulates a classic 8-bit NES-style computer system compiled from Rust to WebAssembly, including CPU instruction execution, PPU (Picture Processing Unit) graphics rendering, and memory-mapped I/O. Each iteration loads a ROM binary and runs 120 frames (2 seconds at 60fps) of emulation, producing a 256x240 RGBA framebuffer per frame that is validated for correctness.

This benchmark tests Wasm execution of a Rust-compiled emulator, which has different code generation patterns than C/Emscripten-compiled modules (using wasm-bindgen for JS interop). The Wasm engine's handling of the emulator's tight instruction dispatch loop, the efficiency of linear memory accesses for PPU framebuffer writes, and the overhead of the wasm-bindgen JS-to-Wasm boundary calls are the primary factors.

Directory: 8bitbench

File Size
build/rust/pkg/emu_bench.js (wasm-bindgen glue) 7.3 KB
benchmark.js (in dir)
build/rust/pkg/emu_bench_bg.wasm (preloaded) 61.9 KB
build/assets/program.bin (preloaded, ROM) 41.0 KB
../utils/polyfills/fast-text-encoding/1.0.3/text.js 9.6 KB

Air

Simulates a key phase of a compiler backend: it constructs intermediate representations (IRs) of code from four different payloads — a Game Boy emulator, a Gaussian blur imaging routine, a TypeScript scanner, and a JavaScript function — then performs liveness analysis and stack allocation on each. The benchmark exercises object allocation, graph traversal, and the kind of data-structure-heavy computation typical of optimizing JIT compilers.

Performance on this benchmark is largely driven by the engine's ability to optimize object-heavy code with many small class instances and polymorphic property accesses. The quality of inline caching for property loads and stores, the efficiency of object allocation and garbage collection of short-lived graph nodes, and the JIT compiler's ability to specialize graph traversal loops all play significant roles.

Directory: ARES-6/Air

File Size
symbols.js 4.9 KB
tmp_base.js 1.9 KB
arg.js 26.6 KB
basic_block.js 4.3 KB
code.js 3.9 KB
frequented_block.js 1.6 KB
inst.js 4.2 KB
opcode.js 51.3 KB
reg.js 4.0 KB
stack_slot.js 3.3 KB
tmp.js 2.2 KB
util.js 4.7 KB
custom.js 3.3 KB
liveness.js 5.6 KB
insertion_set.js 3.3 KB
allocate_stack.js 10.1 KB
payload-gbemu-executeIteration.js 113.3 KB
payload-imaging-gaussian-blur-gaussianBlur.js 116.9 KB
payload-airjs-ACLj8C.js 63.8 KB
payload-typescript-scanIdentifier.js 65.5 KB
benchmark.js 3.0 KB

Babylon

Parses large JavaScript source files using the Babylon parser (the parser behind Babel). Each iteration parses multiple source blobs — including the Air benchmark code, the Basic benchmark code, WebKit inspector source, and the Babylon parser's own source — testing the engine's performance on parser-heavy workloads with complex string processing and AST construction.

This benchmark stresses the engine's string handling subsystem — particularly single-character extraction, string comparison, and substring operations — since parsers are inherently string-processing-intensive. The efficiency of object allocation for AST nodes, inline caching for the many monomorphic call sites in the parser's recursive descent structure, and the JIT compiler's optimization of large switch statements used for token dispatch are the main performance factors.

Directory: ARES-6/Babylon

File Size
index.js (Babylon parser) 241.9 KB
benchmark.js 2.7 KB
air-blob.js (preloaded) 4.1 KB
basic-blob.js (preloaded) 7.8 KB
inspector-blob.js (preloaded) 49.9 KB
babylon-blob.js (preloaded) 2.9 KB

Basic

Implements a complete interpreter for the BASIC programming language, including lexing, parsing, and execution. Each iteration parses and runs BASIC programs featuring control flow constructs (loops, conditionals, GOSUB/RETURN), array operations, string manipulation, and arithmetic — exercising the engine's ability to handle dynamic language interpretation with deep call stacks and frequent object allocation.

The key engine aspects affecting this benchmark are the optimization of dynamically-typed arithmetic and string operations, the efficiency of Map-like data structures used for variable lookup, and the JIT compiler's ability to handle deep, non-inlineable call chains typical of interpreter loops. Garbage collector throughput also matters, as the interpreter creates many temporary AST node and value objects.

Directory: ARES-6/Basic

File Size
ast.js 7.8 KB
basic.js 2.0 KB
caseless_map.js 1.9 KB
lexer.js 4.3 KB
number.js 4.4 KB
parser.js 19.2 KB
random.js 2.5 KB
state.js 3.3 KB
benchmark.js 10.0 KB

Box2D

Runs a JavaScript port of the Box2D 2D physics engine, simulating rigid body dynamics with contact generation, constraint solving, broad-phase collision detection, and integration over multiple time steps. The benchmark exercises floating-point arithmetic, object-oriented polymorphism, and complex data structure manipulation.

This benchmark is sensitive to the engine's optimization of deeply polymorphic object-oriented code. The physics engine uses many virtual method calls across a class hierarchy (shapes, joints, contacts), and the JIT compiler's ability to devirtualize and inline these calls determines throughput. Efficient floating-point representation (avoiding boxing of doubles), and the optimization of property accesses on objects with complex prototype chains are also important.

Directory: Octane

File Size
box2d.js 228.3 KB

Dart-flute-complex-wasm

Runs a complex Flutter UI application compiled from Dart to WebAssembly using dart2wasm. Each iteration instantiates the compiled module and renders 100 frames of the CupertinoTimePicker widget, exercising the Dart runtime, Flutter's widget tree reconciliation, and layout algorithms — all running as a Wasm application with a JS event loop. This benchmark is not run by default due to its GC-dominated workload.

This benchmark tests the engine's WebAssembly GC (WasmGC) proposal implementation, as Dart's compilation to Wasm relies on WasmGC for object allocation and garbage collection rather than using linear memory. The efficiency of the engine's WasmGC object allocation, garbage collection of short-lived Wasm-managed objects, and the performance of WasmGC struct and array access instructions are the dominant factors.

Directory: Dart

File Size
benchmark.js (in dir)
build/flute.complex.dart2wasm.mjs (preloaded JS module) 14.3 KB
build/flute.complex.dart2wasm.wasm (preloaded) 1.4 MB

Dart-flute-todomvc-wasm

Runs a TodoMVC application built with Flutter's Flute framework, compiled from Dart to WebAssembly. Each iteration instantiates the Wasm module and renders 100 frames of the TodoMVC UI, exercising the Dart runtime and Flutter's rendering pipeline with a lighter workload than the complex variant, making it more representative of typical Dart/Flutter web applications.

Like Dart-flute-complex-wasm, this benchmark tests the engine's WasmGC implementation, but with a less GC-intensive workload. The same factors apply — WasmGC struct allocation, GC throughput, and Wasm execution speed — but the lighter workload makes Wasm compilation speed a more significant fraction of the overall time.

Directory: Dart

File Size
benchmark.js (in dir)
build/flute.todomvc.dart2wasm.mjs (preloaded JS module) 14.5 KB
build/flute.todomvc.dart2wasm.wasm (preloaded) 1.7 MB

FlightPlanner

Plans flight routes between airport waypoints using regular expressions to match airway identifiers and geographic calculations to find optimal paths. The benchmark loads a large compressed database of waypoints and airways, then exercises regex matching against real-world aeronautical data combined with graph search algorithms.

The primary engine factor is regular expression performance, particularly the speed of matching patterns against large string datasets. The regex compiler's handling of Unicode-aware matching and the efficiency of repeated small regex operations (as opposed to single complex patterns) are critical. Secondary factors include the engine's decompression of the large zlib-compressed waypoint data during loading, and the optimization of the graph search algorithm's object allocation.

Directory: RexBench/FlightPlanner

File Size
airways.js 181.5 KB
waypoints.js.z (zlib-compressed JS) 2.2 MB
flight_planner.js 60.2 KB
expectations.js 32.8 KB
benchmark.js 1.8 KB

HashSet-wasm

Tests a WebAssembly-compiled hash set data structure performing repeated insertion and lookup operations. The benchmark instantiates a C-compiled WebAssembly module via Emscripten and exercises its hash set implementation, testing Wasm execution speed, memory management, and the JS-to-Wasm interop boundary.

The primary engine factors are WebAssembly compilation speed (for the first iteration, which includes module instantiation) and Wasm execution throughput for subsequent iterations. The quality of the Wasm compiler's register allocation, the efficiency of Wasm linear memory access, and the overhead of JS-to-Wasm boundary crossing in the Emscripten glue code all contribute to the score.

Directory: wasm/HashSet

File Size
build/HashSet.js (Emscripten glue) 26.8 KB
benchmark.js (in dir)
build/HashSet.wasm (preloaded) 291.9 KB

Kotlin-compose-wasm

Runs the Kotlin Compose Multiplatform UI framework compiled to WebAssembly, executing multiple UI workloads: animated visibility transitions, lazy grid layouts (with smooth scrolling and item effects), visual effects, and multi-component rendering. The benchmark loads two Wasm modules (Skiko graphics and the Compose application), multiple image assets and fonts, and renders varying numbers of frames per workload, testing a complete real-world Kotlin/Wasm application stack.

This benchmark tests the engine's ability to handle very large Wasm modules (15+ MB combined) and the WasmGC proposal implementation that Kotlin targets. Wasm compilation speed is significant due to the large module sizes. For execution, the WasmGC object allocation and collection efficiency, the performance of inter-module Wasm calls (Skiko ↔ Compose), and the JS-to-Wasm boundary overhead for the setTimeout and fetch polyfills are the key factors.

Directory: Kotlin-compose

File Size
benchmark.js (in dir)
build/skiko.mjs (preloaded, Skiko graphics module) 549.4 KB
build/skiko.wasm (preloaded) 9.7 MB
build/compose-benchmarks-benchmarks.uninstantiated.mjs (preloaded) 29.8 KB
build/compose-benchmarks-benchmarks.wasm (preloaded) 5.6 MB
build/compose-multiplatform.png (preloaded) 35.0 KB
build/example1_cat.jpg (preloaded) 37.5 KB
build/example1_compose-community-primary.png (preloaded) 17.7 KB
build/jetbrainsmono_italic.ttf (preloaded) 141.6 KB
build/jetbrainsmono_regular.ttf (preloaded) 136.7 KB

ML

Trains small feedforward neural networks using matrix operations and backpropagation. Each iteration constructs networks with various activation functions (sigmoid, ReLU, tanh, etc.) and trains them on logical operations (XOR, AND, OR), exercising dense matrix multiplication, element-wise array operations, and floating-point arithmetic.

This benchmark is dominated by the engine's floating-point arithmetic throughput and its ability to optimize dense array operations, particularly nested loop performance over numeric arrays. The JIT compiler's capacity to eliminate type checks within known-numeric loops and to produce efficient machine code for Math functions (exp, tanh, etc.) is critical.

Directory: ARES-6/ml

File Size
index.js 212.1 KB
benchmark.js 5.9 KB

OfflineAssembler

Parses WebKit's low-level interpreter assembly source code using a regex-based parser that handles macros, labels, instructions, and platform-specific directives. The benchmark processes three large assembly files (LowLevelInterpreter.js, LowLevelInterpreter32_64.js, LowLevelInterpreter64.js) and compares the output against expected results, stressing regex parsing and AST construction.

Performance depends primarily on the regex engine's efficiency with the many small-to-medium regex patterns used for tokenization and parsing. The engine's ability to optimize repeated regex operations on substrings, string concatenation for building output, and the allocation of AST node objects during parsing are the key factors. The recursive descent parsing structure also tests the engine's call stack and function call overhead.

Directory: RexBench/OfflineAssembler

File Size
registers.js 2.2 KB
instructions.js 6.7 KB
ast.js 29.0 KB
parser.js 35.4 KB
file.js 1.8 KB
LowLevelInterpreter.js 58.0 KB
LowLevelInterpreter32_64.js 75.6 KB
LowLevelInterpreter64.js 73.1 KB
InitBytecodes.js 9.1 KB
expected.js 217.9 KB
benchmark.js 2.2 KB

Sunspider

A grouped benchmark that runs 12 classic SunSpider micro-benchmarks as a single combined test: 3d-cube (3D matrix transforms), 3d-raytrace (ray-sphere intersections), base64 (encoding/decoding), crypto-aes (AES encryption), crypto-md5 (MD5 hashing), crypto-sha1 (SHA-1 hashing), date-format-tofte (date formatting), date-format-xparb (alternative date formatting), n-body (gravitational simulation), regex-dna (DNA pattern matching), string-unpack-code (string decompression), and tagcloud (JSON parsing and HTML generation). These are small, focused tests of specific JavaScript features.

These micro-benchmarks individually test narrow engine capabilities: floating-point arithmetic (3d-cube, n-body), bitwise integer operations (crypto-), string manipulation and concatenation (string-unpack-code, tagcloud, base64), regex performance (regex-dna), and Date object operations (date-format-). As a grouped test, the geometric mean of their scores provides a broad measure of baseline engine performance across these fundamental operation types. Because each sub-test is small, JIT compilation warmup and tier-up latency can significantly affect results.

Directory: SunSpider

File Size
3d-cube.js 10.0 KB
3d-raytrace.js 14.6 KB
base64.js 5.3 KB
crypto-aes.js 17.3 KB
crypto-md5.js 10.0 KB
crypto-sha1.js 6.6 KB
date-format-tofte.js 11.8 KB
date-format-xparb.js 12.9 KB
n-body.js 4.5 KB
regex-dna.js 408.8 KB
string-unpack-code.js 167.3 KB
tagcloud.js 175.3 KB

UniPoker

Evaluates and compares poker hands for a 4-player simulation using Unicode card representations. Each iteration deals random hands, classifies them (flush, straight, full house, etc.) using pattern matching and sorting, and determines winners — exercising string comparison, Unicode processing, sorting algorithms, and conditional logic.

This benchmark tests the engine's Unicode string handling — character-level operations on non-ASCII strings (card suits are represented as Unicode symbols), string comparison and sorting with Unicode code point semantics, and the Array.prototype.sort implementation. The engine's efficiency at handling two-byte (non-Latin1) strings and its sorting algorithm's comparison overhead are the primary factors.

Directory: RexBench/UniPoker

File Size
poker.js 13.2 KB
expected.js 3.4 KB
benchmark.js 2.2 KB

WSL

Implements and tests a complete compiler pipeline for the WebKit Shading Language (WSL), a shader language designed as an alternative to WGSL/GLSL. The benchmark loads 148 JavaScript files comprising a full compiler frontend — including lexer, parser, type checker, name resolver, overload resolution, and evaluator — then runs a test suite that parses, type-checks, and evaluates WSL programs. This stresses object-oriented code organization, recursive descent parsing, and complex type system operations.

This benchmark tests the engine's ability to handle a large codebase spread across 148 files with deep class hierarchies and extensive use of instanceof checks, Map/Set collections, and recursive algorithms. The efficiency of prototype chain lookups, the performance of instanceof checks (used extensively in type dispatching), and the optimization of the many small monomorphic methods in the compiler pipeline are the dominant factors. The large number of source files also tests code loading overhead.

Directory: WSL

File Size
148 JavaScript source files ~1–33 KB each
Test.js (final file, contains test suite) 182.4 KB
Notable files: Parse.js (33.3 KB), Checker.js (29.6 KB), Intrinsics.js (25.2 KB)

acorn-wtb

Parses JavaScript source files using the Acorn parser as part of the Web Tooling Benchmark suite. Each iteration parses multiple real-world JavaScript libraries (jQuery, Lodash, Underscore, MooTools, etc.) from the third-party data set, testing parser performance on diverse coding styles. All WTB benchmarks share the same set of third-party input files.

Performance is driven by the engine's optimization of the Acorn parser's string-processing-heavy execution pattern — character code extraction (charCodeAt), string slicing for token extraction, and AST node object allocation. The JIT compiler's ability to specialize the parser's main character-dispatch loop and to optimize the many small helper functions used for token classification are the key factors.

Directory: web-tooling-benchmark

File Size
dist/acorn.bundle.js 251.7 KB
benchmark.js (in dir)
Third-party input files (preloaded, shared across WTB tests):
third_party/jquery-3.7.1.js 285.3 KB
third_party/lodash.core-4.17.21.js 116.0 KB
third_party/backbone-1.6.1.js 80.4 KB
third_party/underscore-1.13.7.js 68.8 KB
third_party/mootools-core-1.6.0.js 162.0 KB
third_party/vue-3.5.18.runtime.esm-browser.js 368.3 KB
third_party/preact-8.2.5.js 20.8 KB
third_party/redux-5.0.1.esm.js 16.8 KB
third_party/redux-5.0.1.min.js 10.3 KB
third_party/speedometer-es2015-test-2.0.js 24.8 KB
third_party/bootstrap-5.3.7.css 280.2 KB
third_party/foundation-6.9.0.css 161.3 KB
third_party/angular-material-20.1.6.css 104.5 KB
third_party/typescript-angular.ts 110.0 KB
third_party/lodash-4.17.4.min.js.map 136.9 KB
third_party/underscore-1.13.7.min.js.map 34.5 KB
third_party/preact-10.27.1.min.module.js.map 85.1 KB
third_party/source-map.min-0.5.7.js.map 248.8 KB
third_party/source-map/lib/mappings.wasm 48.5 KB
third_party/todomvc/react/app.jsx 5.5 KB
third_party/todomvc/react/footer.jsx 1.3 KB
third_party/todomvc/react/todoItem.jsx 2.9 KB

ai-astar

Implements the A* pathfinding algorithm on a 2D grid, finding shortest paths between points while avoiding obstacles. Each iteration builds a grid, places walls, and runs A* search using a priority queue (binary heap), exercising array manipulation, object allocation, and algorithmic control flow.

Performance is influenced by the engine's optimization of array-backed binary heap operations (insertion, extraction, sifting) and the overhead of allocating grid node objects. The JIT compiler's ability to optimize the priority queue's comparison-heavy loops and the engine's efficiency at property accesses on uniform node objects (which should form a monomorphic shape) are the key factors.

Directory: SeaMonster

File Size
ai-astar.js 516.4 KB

argon2-wasm

Hashes and verifies passwords using the Argon2id memory-hard password hashing algorithm compiled from C to WebAssembly. Each iteration hashes nine different passwords (including Unicode strings) with random salts and then verifies each hash, exercising the Wasm engine's handling of memory-intensive computation with deliberate cache-unfriendly access patterns designed for password security.

This benchmark uniquely tests the Wasm engine's memory subsystem under adversarial access patterns. Argon2 deliberately performs cache-unfriendly memory accesses across a 1 MB working set to resist GPU-based attacks. The efficiency of the Wasm engine's linear memory implementation, its interaction with the CPU cache hierarchy, and the Wasm compiler's handling of the algorithm's irregular memory access pattern are the critical factors.

Directory: wasm/argon2

File Size
build/argon2.js (Emscripten glue) 27.8 KB
benchmark.js (in dir)
build/argon2.wasm.z (preloaded, zlib-compressed) 12.9 KB

async-fs

Simulates asynchronous file system operations (creating, reading, writing, listing, deleting files and directories) using async generator functions. Each iteration builds a virtual file system tree and performs operations through async iteration protocols, testing the engine's optimization of async generators and for await...of loops.

This benchmark tests the engine's async generator implementation — specifically the overhead of the combined async + generator state machine. Each yield in an async generator involves both generator suspension and promise creation/resolution. The engine's ability to optimize away intermediate promise allocations in for await...of loops over async generators, and to minimize the per-yield suspension/resumption cost, are the dominant factors.

Directory: generators

File Size
async-file-system.js 9.2 KB

babel-minify-wtb

Minifies JavaScript source code using babel-minify (formerly Babili), a minifier built on the Babel toolchain. Each iteration applies a pipeline of code transformations including dead code elimination, constant folding, identifier mangling, and whitespace removal to the shared WTB input files.

Performance depends on the engine's optimization of multiple analysis and transformation passes over AST structures. Minification involves scope analysis for identifier mangling, constant propagation requiring numeric and string evaluation, and dead code elimination through control flow analysis. The engine's ability to inline the many small transformation functions and to efficiently handle the Map and Set data structures used for scope tracking significantly affects throughput.

Directory: web-tooling-benchmark

File Size
dist/babel-minify.bundle.js 2.8 MB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

babel-wtb

Transpiles modern JavaScript (ES2015+) source code to ES5 using the Babel compiler. Each iteration transforms multiple real-world JavaScript files from the shared WTB third-party data set, testing the performance of AST construction, traversal, and code generation.

This benchmark heavily exercises the engine's ability to optimize large, deeply-nested AST traversal and transformation pipelines. The Babel compiler repeatedly walks tree structures using visitor patterns with dynamic dispatch, creates large numbers of short-lived AST node objects, and performs extensive string concatenation during code generation. JIT optimization of polymorphic call sites in the visitor infrastructure and efficient garbage collection of the many intermediate objects are key performance factors.

Directory: web-tooling-benchmark

File Size
dist/babel.bundle.js 5.6 MB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

babylon-wtb

Parses JavaScript source code using the Babylon parser (the parser underlying Babel, distinct from the ARES-6 Babylon benchmark which uses an older version). Each iteration parses multiple real-world JavaScript files, testing parser throughput with support for modern language features including JSX, TypeScript annotations, and decorators.

Like acorn-wtb, this benchmark is dominated by string-processing performance — character-level scanning using charCodeAt, token extraction via substring/slice, and heavy object allocation for AST nodes. The Babylon parser's support for additional syntax extensions (JSX, TypeScript, decorators) means more branching in the tokenizer and parser, making branch prediction and speculative optimization in the JIT compiler more important than for simpler parsers.

Directory: web-tooling-benchmark

File Size
dist/babylon.bundle.js 360.6 KB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

babylonjs-scene-es5

Renders a complex 3D scene using the Babylon.js engine loaded from the ES5 bundle. The scene includes a pirate fort model (8.2 MB glTF), a cannon model, and a particle effects system. Each iteration loads the 3D assets, constructs the scene graph, and renders 100 animation frames with lighting and camera movement, testing the full 3D rendering pipeline in JavaScript. This benchmark is not run by default.

This benchmark tests sustained JavaScript execution performance of a large 3D application. Beyond the startup compilation cost, the execution phase stresses the engine's optimization of Babylon.js's rendering loop — matrix multiplication, scene graph traversal, binary data parsing (glTF), and particle system updates. The engine's ability to optimize the framework's deeply polymorphic class hierarchy and to handle the large working set of live objects without GC pauses are key.

Directory: babylonjs

File Size
dist/bundle.es5.min.js 11.6 MB
benchmark/scene.js 1.5 KB
data/particles.json (preloaded) 37.1 KB
data/pirateFort.glb (preloaded) 8.2 MB
data/cannon.glb (preloaded) 133.5 KB

babylonjs-scene-es6

The same complex 3D scene rendering workload as babylonjs-scene-es5, but using the ES6 Babylon.js bundle. This tests the same pirate fort scene with particle effects using modern JavaScript language features.

The same engine factors as babylonjs-scene-es5 apply, with the additional consideration of whether the JIT compiler produces better code for native ES6 class syntax (used in the ES6 bundle) compared to the prototype-based patterns in the ES5 bundle. The smaller bundle size also means less compilation overhead, making execution performance a larger fraction of the total time.

Directory: babylonjs

File Size
dist/bundle.es6.min.js 8.9 MB
benchmark/scene.js 1.5 KB
data/particles.json (preloaded) 37.1 KB
data/pirateFort.glb (preloaded) 8.2 MB
data/cannon.glb (preloaded) 133.5 KB

babylonjs-startup-es5

Measures the startup performance of loading and initializing the Babylon.js 3D engine from its ES5-transpiled bundle. Each iteration evaluates the full minified Babylon.js library via eval, then instantiates a test scene and renders 30 frames, measuring both the code parsing/compilation overhead and initial engine setup.

This is the heaviest startup benchmark in the suite, requiring the engine to parse and compile an 11.6 MB ES5 JavaScript bundle. Parser throughput, bytecode generation speed, and bytecode caching effectiveness across iterations are the dominant factors. The ES5 version specifically tests how the engine handles older JavaScript patterns (prototype-based classes, var declarations, explicit Object.defineProperty calls) that ES5 transpilation produces.

Directory: babylonjs

File Size
benchmark/startup.js 3.0 KB
dist/bundle.es5.min.js (preloaded) 11.6 MB
../utils/StartupBenchmark.js 4.1 KB

babylonjs-startup-es6

Measures the startup performance of loading and initializing the Babylon.js 3D engine from its ES6 (modern JavaScript) bundle. This is the same workload as babylonjs-startup-es5 but uses the ES6 bundle which is smaller due to fewer transpilation artifacts, testing how the engine handles modern JavaScript syntax during compilation.

Compared to the ES5 variant, this tests the parser and compiler's handling of modern JavaScript syntax — native classes, arrow functions, let/const, destructuring, template literals, etc. The ES6 bundle is 23% smaller (8.9 MB vs 11.6 MB), so the comparison between ES5 and ES6 scores reveals whether the engine's parser and compiler have been optimized for modern syntax, and whether the reduced code size translates to proportionally faster compilation.

Directory: babylonjs

File Size
benchmark/startup.js 3.0 KB
dist/bundle.es6.min.js (preloaded) 8.9 MB
../utils/StartupBenchmark.js 4.1 KB

bigint-bigdenary

Performs arbitrary-precision decimal arithmetic using the BigDenary library, which represents decimal numbers as BigInt-backed rational numbers. The benchmark tests addition, multiplication, division, and comparison of large decimal values, exercising BigInt operations with frequent conversions between representations.

This benchmark tests BigInt performance in a different usage pattern than the cryptographic benchmarks — it exercises frequent conversions between BigInt and string/number representations, BigInt division (which many engines optimize less than multiplication), and the overhead of mixed BigInt/Number arithmetic. The engine's optimization of BigInt-to-string conversion and string-to-BigInt parsing also matter.

Directory: bigint

File Size
bigdenary-bundle.js 11.1 KB
bigdenary-benchmark.js 2.6 KB

bigint-noble-bls12-381

Executes BLS12-381 pairing-based cryptography operations using the noble-bls12-381 library, implementing BLS signature schemes in pure JavaScript with BigInt. This involves computationally intensive finite field arithmetic over 381-bit prime fields and pairing computations, representing one of the heaviest BigInt workloads in the suite.

This is the most computationally intensive BigInt benchmark in the suite. Performance is almost entirely determined by the engine's BigInt multiplication and modular reduction throughput for 381-bit and larger values. The ability of the engine to use efficient algorithms for large-number multiplication (Karatsuba, Toom-Cook) rather than schoolbook multiplication, and to minimize allocation of intermediate BigInt objects, are critical.

Directory: bigint

File Size
web-crypto-sham.js 238.1 KB
noble-bls12-381-bundle.js 89.0 KB
noble-benchmark.js 1.4 KB

bigint-noble-ed25519

Performs Ed25519 elliptic curve digital signature operations (key generation, signing, and verification) using the noble-ed25519 library, which implements all cryptographic primitives in pure JavaScript using BigInt. The benchmark exercises JavaScript's native BigInt type with large-number modular arithmetic, field operations, and point multiplication on the Curve25519 elliptic curve.

This benchmark is a direct test of the engine's BigInt implementation. The speed of BigInt modular arithmetic (multiplication, modular reduction, exponentiation), the efficiency of BigInt memory allocation for intermediate results, and the overhead of BigInt operator dispatch are the dominant factors. Engines that implement BigInt operations in optimized native code (rather than falling through to a generic slow path) will see large gains.

Directory: bigint

File Size
web-crypto-sham.js 238.1 KB
noble-ed25519-bundle.js 62.2 KB
noble-benchmark.js 1.4 KB

bigint-noble-secp256k1

Computes secp256k1 elliptic curve operations (the curve used in Bitcoin and Ethereum) using the noble-secp256k1 library in pure JavaScript with BigInt. The benchmark exercises point multiplication, ECDSA signature generation, and modular arithmetic over a 256-bit prime field.

Like the other BigInt cryptography benchmarks, performance depends on the engine's BigInt arithmetic implementation, specifically for 256-bit values. The efficiency of modular multiplication and inversion over the secp256k1 prime field, and the engine's ability to avoid excessive memory allocation for the many intermediate BigInt values produced during point multiplication, are the key factors.

Directory: bigint

File Size
web-crypto-sham.js 238.1 KB
noble-secp256k1-bundle.js 149.5 KB
noble-benchmark.js 1.4 KB

bigint-paillier

Implements the Paillier additive homomorphic encryption scheme using BigInt, including key generation, encryption, and decryption with large prime numbers. The benchmark exercises modular exponentiation and multiplication with very large BigInt values typical of public-key cryptography.

Performance is dominated by BigInt modular exponentiation with very large operands (1024+ bits). The engine's implementation of modular exponentiation (square-and-multiply), the efficiency of its big-number multiplication algorithm at these larger sizes, and the overhead of repeated BigInt object allocation during the exponentiation loop are the primary factors.

Directory: bigint

File Size
web-crypto-sham.js 238.1 KB
paillier-bundle.js 8.9 KB
paillier-benchmark.js 2.7 KB

bomb-workers

Spawns 26 Web Workers simultaneously, each running a different SunSpider-style computational task (3D ray tracing, n-body simulation, crypto, string operations, regex, date formatting, etc.). Each iteration waits for all workers to complete, testing the engine's ability to handle concurrent JavaScript execution across many parallel contexts. This benchmark only runs in a browser environment.

The key engine factor is the overhead and scalability of Web Worker creation and concurrent execution. The engine's ability to compile and execute code independently across 26 parallel JS contexts, the memory overhead per Worker (each needing its own heap, stack, and JIT compilation state), and the efficiency of the Worker message-passing infrastructure (postMessage serialization) determine performance. This is the only benchmark that directly tests the engine's parallelism and multi-context scaling.

Directory: worker

File Size
bomb.js 3.2 KB
bomb-subtests/3d-raytrace.js (preloaded) —
bomb-subtests/access-nbody.js (preloaded) —
bomb-subtests/3d-morph.js (preloaded) —
bomb-subtests/3d-cube.js (preloaded) —
bomb-subtests/access-fannkuch.js (preloaded) —
bomb-subtests/access-binary-trees.js (preloaded) —
bomb-subtests/access-nsieve.js (preloaded) —
bomb-subtests/bitops-bitwise-and.js (preloaded) —
bomb-subtests/bitops-nsieve-bits.js (preloaded) —
bomb-subtests/controlflow-recursive.js (preloaded) —
bomb-subtests/bitops-3bit-bits-in-byte.js (preloaded) —
bomb-subtests/bitops-bits-in-byte.js (preloaded) —
bomb-subtests/crypto-aes.js (preloaded) —
bomb-subtests/crypto-md5.js (preloaded) —
bomb-subtests/crypto-sha1.js (preloaded) —
bomb-subtests/date-format-tofte.js (preloaded) —
bomb-subtests/date-format-xparb.js (preloaded) —
bomb-subtests/math-cordic.js (preloaded) —
bomb-subtests/math-partial-sums.js (preloaded) —
bomb-subtests/math-spectral-norm.js (preloaded) —
bomb-subtests/string-base64.js (preloaded) —
bomb-subtests/string-fasta.js (preloaded) —
bomb-subtests/string-validate-input.js (preloaded) —
bomb-subtests/string-tagcloud.js (preloaded) —
bomb-subtests/string-unpack-code.js (preloaded) —
bomb-subtests/regexp-dna.js (preloaded) —

cdjs

Simulates an aircraft collision detection system derived from the CD_x benchmark from Purdue University. Each iteration simulates multiple frames of aircraft movement and uses a red-black tree-based spatial algorithm to detect collisions between aircraft trajectories, exercising 2D/3D vector math, tree data structures, and object allocation patterns common in simulation workloads.

Performance is primarily influenced by the engine's ability to optimize object-oriented code with class hierarchies (vector, motion, and tree node classes), the efficiency of inline caches at polymorphic call sites in the collision detection algorithm, and the garbage collector's handling of the many temporary vector objects created during geometric calculations.

Directory: cdjs

File Size
constants.js 1.9 KB
util.js 3.1 KB
red_black_tree.js 13.0 KB
call_sign.js 1.8 KB
vector_2d.js 2.2 KB
vector_3d.js 2.7 KB
motion.js 5.7 KB
reduce_collision_set.js 5.9 KB
simulator.js 2.2 KB
collision.js 1.8 KB
collision_detector.js 3.3 KB
benchmark.js 3.7 KB

chai-wtb

Runs assertion operations using the Chai assertion library, a popular testing utility. Each iteration exercises various assertion styles (expect, should, assert) across diverse data types and comparison operations, testing property access, prototype chain walking, and deep equality comparison.

This benchmark stresses the engine's prototype chain lookup and property access mechanisms. Chai's fluent API (expect(x).to.be.a('string')) relies on getter-based property chains that walk the prototype hierarchy, requiring efficient hidden class transitions and inline cache handling for property accesses on chainable assertion objects. Deep equality comparison exercises recursive object traversal and type-checking operations, making typeof, instanceof, and Object.keys enumeration performance significant factors.

Directory: web-tooling-benchmark

File Size
dist/chai.bundle.js 530.4 KB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

crypto

Implements RSA encryption and decryption using arbitrary-precision integer arithmetic in pure JavaScript. Each iteration generates RSA keys and performs encrypt/decrypt cycles, exercising BigInteger operations including modular exponentiation, Montgomery multiplication, and Barrett reduction.

Performance is driven by the engine's optimization of tight integer arithmetic loops operating on arrays of 32-bit values that represent big numbers. The JIT compiler's ability to recognize and optimize array index arithmetic, bounds check elimination, and integer overflow detection in the BigInteger implementation are the critical factors. This predates native BigInt and implements its own arbitrary-precision integer library.

Directory: Octane

File Size
crypto.js 48.0 KB

delta-blue

Runs the DeltaBlue incremental constraint solver, an algorithm for maintaining a network of one-way constraints with hierarchical priorities. Each iteration builds constraint graphs and propagates changes through them, stressing polymorphic method dispatch, object allocation, and control flow.

This is a classic test of polymorphic inline cache (PIC) effectiveness. The constraint solver dispatches through a hierarchy of constraint types (UnaryConstraint, BinaryConstraint, ScaleConstraint, etc.), and the engine's ability to handle megamorphic call sites — where the same call site encounters many different receiver types — largely determines performance. Object property access speed and prototype chain lookup efficiency are also critical.

Directory: Octane

File Size
deltablue.js 25.7 KB

dotnet-aot-wasm

Runs the same .NET application as dotnet-interp-wasm, but compiled with ahead-of-time (AOT) compilation to WebAssembly, where C# code is directly compiled to Wasm instructions rather than being interpreted. This produces a much larger Wasm binary but runs significantly faster, and the benchmark uses larger workload sizes to compensate. It tests the Wasm engine's performance with a large, AOT-compiled application.

With the 8 MB AOT-compiled Wasm binary, this benchmark heavily stresses the Wasm compiler's throughput on large modules — compilation time may dominate the first iteration. For execution, the Wasm engine's code quality for the AOT-generated instruction patterns (which differ from C/Emscripten output), the efficiency of linear memory access for the .NET managed heap simulation, and the handling of the many internal Wasm function calls generated by the AOT compiler are the key factors.

Directory: wasm/dotnet

File Size
aot.js 1 line
benchmark.js (in dir)
build-aot/wwwroot/_framework/dotnet.js (preloaded) 40.5 KB
build-aot/wwwroot/_framework/dotnet.native.js (preloaded) 126.9 KB
build-aot/wwwroot/_framework/dotnet.runtime.js (preloaded) 194.8 KB
build-aot/wwwroot/_framework/dotnet.native.wasm (preloaded) 8.0 MB
build-aot/wwwroot/_framework/icudt_CJK.dat (preloaded) 956.4 KB
build-aot/wwwroot/_framework/dotnet.wasm (preloaded, app DLL) 96.5 KB
build-aot/wwwroot/_framework/System.Private.CoreLib.wasm (preloaded) 1.2 MB
build-aot/wwwroot/_framework/System.Text.Json.wasm (preloaded) 233.2 KB
Additional System.*.wasm assemblies (preloaded, 12 files) 5–39 KB each

dotnet-interp-wasm

Runs a .NET application compiled to WebAssembly using the .NET interpreter mode, which interprets IL (Intermediate Language) bytecode within the Wasm runtime. Each iteration executes two workloads: a batch of asynchronous scheduling tasks (BenchTasks) and a ray tracing renderer, both written in C#. The benchmark loads the full .NET runtime (dotnet.native.wasm), ICU internationalization data, and multiple .NET system assembly DLLs as Wasm modules.

This benchmark tests the engine's ability to handle multiple Wasm module instantiations (the main runtime plus 15+ assembly DLLs as separate modules) and the Wasm execution performance of an interpreter running within Wasm — a doubly-interpreted execution model. The Wasm engine's compilation speed for the 2.8 MB runtime module, the efficiency of dynamic JS module imports used by the .NET runtime, and the JS-to-Wasm interop overhead for the async scheduling bridge are the key factors.

Directory: wasm/dotnet

File Size
interp.js 1 line
benchmark.js (in dir)
build-interp/wwwroot/_framework/dotnet.js (preloaded) 40.5 KB
build-interp/wwwroot/_framework/dotnet.native.js (preloaded) 122.7 KB
build-interp/wwwroot/_framework/dotnet.runtime.js (preloaded) 194.8 KB
build-interp/wwwroot/_framework/dotnet.native.wasm (preloaded) 2.8 MB
build-interp/wwwroot/_framework/icudt_CJK.dat (preloaded) 956.4 KB
build-interp/wwwroot/_framework/dotnet.wasm (preloaded, app DLL) 96.5 KB
build-interp/wwwroot/_framework/System.Private.CoreLib.wasm (preloaded) 1.2 MB
build-interp/wwwroot/_framework/System.Text.Json.wasm (preloaded) 233.2 KB
Additional System.*.wasm assemblies (preloaded, 12 files) 5–39 KB each

doxbee-async

Performs the same asynchronous file versioning simulation as doxbee-promise, but uses async/await syntax instead of explicit Promise chains. This tests the engine's ability to optimize async function suspension and resumption compared to manual promise wiring.

This benchmark tests the engine's async/await implementation. The key factors are the overhead of async function state machine generation, the efficiency of suspension (at await) and resumption (when the awaited promise resolves), and how well the engine can optimize away intermediate promise allocations in async function chains. Comparing this with doxbee-promise reveals whether the engine has specific optimizations for async/await beyond desugaring to promises.

Directory: simple

File Size
doxbee-async.js 5.4 KB

doxbee-promise

Simulates a sequence of asynchronous file versioning operations (creating directories, writing files, reading stats, linking) using explicit Promise chains. Each iteration exercises microtask scheduling, promise resolution, and the overhead of chained .then() callbacks for coordinating multi-step async workflows.

This benchmark directly measures the engine's Promise implementation performance. The overhead of creating Promise objects, scheduling microtask queue callbacks via .then(), and the resolution chain traversal are the dominant factors. Engines that can optimize promise allocation (e.g., avoiding full object allocation for resolved promises) and minimize microtask scheduling overhead will perform better.

Directory: simple

File Size
doxbee-promise.js 5.9 KB

earley-boyer

Executes two combined benchmarks: an Earley parser for context-free grammars and a Boyer-Moore theorem prover, both automatically translated from Scheme to JavaScript. The workload stresses dynamic dispatch, deeply nested closures, and the engine's ability to optimize code translated from functional programming patterns.

This benchmark tests the engine's handling of code patterns uncommon in hand-written JavaScript: deeply nested closures capturing many variables, cons-cell-style linked list allocation, and frequent use of first-class functions as arguments. The efficiency of closure allocation and variable capture, tail-call-like recursive patterns, and the garbage collector's ability to handle high allocation rates of small, short-lived cons cells are the primary factors.

Directory: Octane

File Size
earley-boyer.js 195.1 KB

espree-wtb

Parses JavaScript source code using Espree, the parser used by ESLint. Each iteration parses multiple real-world JavaScript files, testing an ECMAScript-compliant parser that produces ESTree-format AST nodes.

As a parser benchmark, performance is primarily governed by the engine's string processing and object allocation throughput. Espree is built on top of Acorn with additional ESLint-specific AST extensions, so the same factors apply: charCodeAt-based character scanning, token string extraction, and AST node allocation. The additional comment and token collection that Espree performs (for ESLint's comment-based directives) adds array push and object creation overhead, making allocation fast paths and nursery GC efficiency relevant.

Directory: web-tooling-benchmark

File Size
dist/espree.bundle.js 542.3 KB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

esprima-next-wtb

Parses JavaScript source code using esprima-next, an updated version of the Esprima parser with support for modern ECMAScript features. Each iteration parses the shared WTB input files, testing parser performance and ESTree AST construction.

Esprima-next uses a class-based parser architecture with method calls for each grammar production, making the engine's optimization of method dispatch on a single receiver class critical. The parser maintains state through instance properties that are read and written frequently in tight loops, so the JIT compiler's ability to optimize property accesses on a monomorphic receiver and to inline the many small parsing methods directly affects scanning and parsing throughput.

Directory: web-tooling-benchmark

File Size
dist/esprima-next.bundle.js 280.5 KB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

first-inspector-code-load

Measures the time to parse and compile a large JavaScript source file (a minified version of the WebKit Web Inspector frontend) by wrapping it in a unique function on each iteration and evaluating it via indirect eval. This tests the engine's first-load code parsing and compilation pipeline without benefiting from bytecode caching, since each iteration wraps the payload in a differently-named function.

This benchmark directly measures the speed of the engine's parser and bytecode compiler on a large (2.1 MB) real-world JavaScript file. The efficiency of lexical analysis, AST construction, and bytecode generation are the dominant factors. Since each iteration uses a unique wrapper function name, the engine cannot reuse cached bytecode, making raw parsing throughput the bottleneck.

Directory: code-load

File Size
code-first-load.js 1.9 KB
inspector-payload-minified.js (preloaded) 2.1 MB

gaussian-blur

Applies a Gaussian blur filter to image data using IIR (Infinite Impulse Response) filtering. The benchmark processes pixel data with forward and backward passes through filter coefficients, testing floating-point arithmetic, typed array access patterns, and tight loop performance.

This benchmark is a pure numeric computation test, dominated by the engine's ability to generate efficient machine code for tight loops iterating over pixel data arrays with floating-point arithmetic. Loop unrolling, floating-point operation throughput, and the elimination of redundant array bounds checks in the sequential access pattern are the main engine factors.

Directory: SeaMonster

File Size
gaussian-blur.js 8.4 KB

gbemu

Emulates a complete Game Boy system including the Z80-derived CPU, timer, memory-mapped I/O, and graphics (tile/sprite rendering with scanline-based PPU). Each iteration runs a boot ROM through thousands of CPU cycles, exercising switch-heavy dispatch, typed array manipulation, and bitwise operations.

The dominant engine factors are the optimization of large switch statements (the CPU instruction decoder), typed array (Uint8Array) access performance simulating the Game Boy's memory, and bitwise/integer arithmetic. The JIT compiler's ability to generate efficient code for switch-based dispatch patterns and to optimize typed array bounds checking in hot loops is decisive.

Directory: Octane

File Size
gbemu-part1.js 50.8 KB
gbemu-part2.js 465.1 KB

gcc-loops-wasm

Runs a set of compute-intensive loop kernels derived from GCC optimization test cases, compiled from C to WebAssembly. The benchmark exercises the Wasm engine's ability to optimize tight numerical loops with various patterns including reduction, array traversal, and conditional accumulation.

This is a focused test of the Wasm engine's loop optimization capabilities. The quality of loop-invariant code motion, strength reduction, and induction variable optimization in the Wasm compiler directly affects performance. Since the loops are tight numeric kernels, the engine's ability to keep values in registers and minimize Wasm linear memory traffic is critical.

Directory: wasm/gcc-loops

File Size
build/gcc-loops.js (Emscripten glue) 116.7 KB
benchmark.js (in dir)
build/gcc-loops.wasm (preloaded) 144.9 KB

hash-map

Implements and exercises a HashMap data structure based on Apache Harmony's design, testing insertion, lookup, deletion, and iteration with various key types. The benchmark stresses hash computation, collision handling, dynamic resizing, and iterator performance.

Performance is driven by the engine's optimization of property access patterns on plain objects used as hash buckets, integer arithmetic for hash computation and bucket indexing, and the efficiency of object allocation for hash entries. The JIT compiler's ability to specialize the hot lookup and insertion paths, and the engine's Array implementation for the underlying bucket storage, are the primary factors.

Directory: simple

File Size
hash-map.js 17.1 KB

intl

A grouped benchmark that tests the ECMAScript Internationalization API (Intl) across five sub-benchmarks: DateTimeFormat, ListFormat, RelativeTimeFormat, NumberFormat, and PluralRules. Each sub-benchmark creates Intl formatter objects with various locale and option combinations and exercises them with different inputs, testing the engine's implementation of locale-sensitive formatting operations.

This benchmark tests the engine's native Intl API implementation, which is typically backed by the ICU (International Components for Unicode) library. The overhead of Intl object construction (which involves locale resolution and pattern compilation), the speed of formatting operations, and the efficiency of caching resolved locale data across repeated formatter invocations are the dominant factors. This is primarily a test of the engine's C++ built-in implementation rather than JIT-compiled JavaScript.

Directory: intl

File Size
src/helper.js 645 B
src/DateTimeFormat.js 2.2 KB
src/ListFormat.js 1.3 KB
src/NumberFormat.js 2.2 KB
src/PluralRules.js 1.1 KB
src/RelativeTimeFormat.js 1.4 KB
benchmark.js (in dir)

j2cl-box2d-wasm

Runs the Box2D 2D physics engine compiled from Java to WebAssembly using J2CL (Java to Closure-style JavaScript) and then to Wasm. Each iteration performs 5 internal iterations of the physics simulation, exercising the Wasm engine with code generated through the J2CL Java-to-Wasm compilation pipeline.

This benchmark tests the Wasm engine's handling of code patterns generated by the J2CL Java-to-Wasm compiler, which produces different instruction patterns than C/Emscripten or Rust/wasm-bindgen toolchains. The Wasm compiler's optimization of J2CL's object model emulation, virtual method dispatch patterns, and the overhead of the instantiateAsync JS-to-Wasm bootstrap are the distinguishing factors.

Directory: wasm/j2cl-box2d

File Size
benchmark.js (in dir)
build/Box2dBenchmark_j2wasm_entry.js 8.5 KB
build/Box2dBenchmark_j2wasm_binary.wasm (preloaded) 81.9 KB

js-tokens

Tokenizes JavaScript source code using a state machine driven by regular expressions. Each iteration scans input text and classifies tokens (identifiers, numbers, strings, operators, etc.) by matching against regex patterns, testing the interplay between regex execution and generator-based token yielding.

This benchmark tests the interaction between two engine subsystems: the regex engine (for token matching) and the generator implementation (for yielding tokens). The regex matching overhead per token, the generator yield/resume cost, and the efficiency of lastIndex-based stateful regex matching (used for sequential tokenization) are the primary factors. The interleaving of these two subsystems makes it a unique test of how well they compose.

Directory: generators

File Size
js-tokens.js 22.3 KB

jsdom-d3-startup

Measures the startup performance of loading jsdom (a pure-JavaScript DOM implementation) and D3.js (a data visualization library), then rendering map visualizations of US county data and airport locations. Each iteration evaluates the combined minified bundle, parses CSV and GeoJSON data, and produces SVG markup, testing code compilation, DOM manipulation, and data processing.

This is one of the heaviest startup benchmarks, testing the engine's ability to quickly parse, compile, and execute a 3.6 MB minified JavaScript bundle. The parser and bytecode compiler throughput dominate the first iteration. Subsequent iterations test bytecode caching effectiveness. The execution phase also tests string-heavy DOM API simulation (innerHTML construction, attribute manipulation) and JSON parsing of the 2.9 MB GeoJSON data.

Directory: jsdom-d3-startup

File Size
benchmark.js (in dir)
dist/bundle.min.js (preloaded) 3.6 MB
data/counties-albers-10m.json (preloaded) 2.9 MB
data/airports.csv (preloaded) 145.5 KB
../utils/StartupBenchmark.js 4.1 KB

json-parse-inspector

Repeatedly deserializes a large JSON string (captured from a WebKit Web Inspector session) back into a JavaScript object using JSON.parse. This is the complementary benchmark to json-stringify-inspector, testing the engine's JSON parser performance on the same complex, real-world data structure.

This benchmark tests the engine's native JSON.parse implementation. The speed of the JSON tokenizer (scanning numbers, strings with escape sequences, structural characters), object and array construction during parsing, and string interning for repeated property names are the dominant factors. Memory allocation efficiency for the many objects and arrays created during parsing also plays a significant role.

Directory: SeaMonster

File Size
inspector-json-payload.js.z (zlib-compressed JS data) 326.8 KB
json-parse-inspector.js 1.5 KB

json-stringify-inspector

Repeatedly serializes a large, deeply nested JavaScript object (captured from a WebKit Web Inspector session) to a JSON string using JSON.stringify. The benchmark tests the engine's JSON serializer performance on complex, real-world object graphs with varied value types.

This benchmark directly tests the engine's native JSON.stringify implementation, which is typically written in C++ rather than JavaScript. The speed of recursive object traversal, property enumeration, string escaping, and string builder/concatenation within the serializer determine performance. The engine's ability to handle deep object graphs without excessive recursion overhead and to efficiently produce large output strings are the key factors.

Directory: SeaMonster

File Size
inspector-json-payload.js.z (zlib-compressed JS data) 326.8 KB
json-stringify-inspector.js 1.5 KB

lazy-collections

Implements lazy evaluation of data collections using generator functions with pipe-based composition. The benchmark chains operations like map, filter, take, and reduce as generators that yield elements on demand, testing the engine's ability to optimize chains of generator-to-generator data flow without materializing intermediate collections.

The key engine factor is the overhead of chained generator-to-generator calls — each element passes through multiple generator frames, each with its own suspension/resumption cost. The engine's ability to optimize the iterator protocol (reducing the cost of {value, done} object allocation per element) and to inline or flatten generator chains into a single state machine would be transformative but is currently beyond most engines.

Directory: generators

File Size
lazy-collections.js 18.3 KB

lebab-wtb

Transforms ES5 JavaScript code to modern ES2015+ syntax using Lebab (the reverse of Babel). Each iteration converts old-style code patterns (var to let/const, function to arrow, etc.) in the WTB input files. This benchmark is disabled by default as converting ES5 to ES6+ is no longer considered a realistic scenario.

Lebab performs pattern-matching-based AST transformations, searching for ES5 idioms and replacing them with modern equivalents. This exercises the engine's optimization of tree-walking visitor functions, deep structural comparison of AST subtrees, and scope analysis for safe variable rebinding (var to let/const). The many small transform plugins each perform independent passes, testing function call overhead and the JIT compiler's ability to handle diverse but structurally similar code patterns across transform modules.

Directory: web-tooling-benchmark

File Size
dist/lebab.bundle.js 2.1 MB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

mandreel

Executes a large game engine workload that was compiled from C/C++ to JavaScript by the Mandreel compiler. The code uses typed arrays extensively to simulate a linear memory model, testing the engine's performance on machine-translated code patterns including computed gotos, pointer arithmetic emulation, and tight numeric loops.

This benchmark stresses the engine's ability to optimize machine-generated code patterns that differ substantially from idiomatic JavaScript. Typed array performance is paramount — virtually all memory operations go through typed array load/store. The JIT compiler's optimization of integer arithmetic used for pointer emulation, bounds check elimination for typed array accesses, and the handling of very large functions with complex control flow graphs are the key factors.

Directory: Octane

File Size
mandreel.js 5.0 MB

mobx-startup

Measures the startup performance of loading and initializing the MobX state management library. Each iteration evaluates the full minified MobX bundle via eval, then runs its reactive state management test, measuring both code compilation/parsing overhead and initial execution — with source code reuse across iterations to test bytecode caching effectiveness.

This benchmark tests the engine's code compilation pipeline speed and bytecode caching. The dominant factor is how quickly the engine can parse and compile a minified 72 KB library via eval. Source code reuse across iterations specifically tests whether the engine can cache and reuse compiled bytecode for repeated evaluations of identical source text. The initial (uncached) iteration tests raw parser/compiler throughput.

Directory: mobx

File Size
benchmark.js (in mobx/)
dist/bundle.es6.min.js (preloaded) 71.6 KB
../utils/StartupBenchmark.js 4.1 KB

multi-inspector-code-load

Evaluates the same minified WebKit Web Inspector payload as first-inspector-code-load, but wraps it in one of 20 cycling function names, allowing the engine to benefit from bytecode caching on repeated evaluations. This tests how well the engine's compilation cache handles re-parsing the same large source text across multiple iterations.

This benchmark specifically tests the engine's bytecode caching and code reuse mechanisms. The key differentiator from first-inspector-code-load is whether the engine can recognize that the function body is identical across iterations and skip redundant parsing/compilation. Engines with effective bytecode caching will show a large speedup over first-inspector-code-load on this benchmark.

Directory: code-load

File Size
code-multi-load.js 2.0 KB
inspector-payload-minified.js (preloaded) 2.1 MB

navier-stokes

Solves the incompressible Navier-Stokes equations for 2D fluid dynamics on a grid using iterative methods. Each iteration performs diffusion, advection, and projection steps with dense array operations and floating-point arithmetic, testing numeric computation throughput and array access performance.

This benchmark is a straightforward test of the engine's numeric loop optimization. The core computation involves tight nested loops accessing regular JavaScript arrays of floats, so the engine's ability to avoid boxing floating-point values, eliminate redundant array bounds checks, and generate efficient machine code for sequential array traversal are the dominant factors. It represents the classic "numeric JavaScript" workload.

Directory: Octane

File Size
navier-stokes.js 12.9 KB

octane-code-load

Compiles and loads the Google Closure Library base.js and jQuery source code, testing how quickly the engine can parse, compile, and execute large real-world JavaScript libraries that use a variety of coding patterns and constructs.

This benchmark tests the engine's code compilation pipeline — parser throughput, bytecode generation, and initial baseline JIT compilation. Unlike the inspector code-load benchmarks, this includes actual execution of the loaded code, so the efficiency of the initial non-optimized execution tier also matters.

Directory: Octane

File Size
code-first-load.js 115.4 KB

pdfjs

Renders a PDF document using Mozilla's PDF.js library compiled into a single benchmark file. The workload includes stream parsing, decompression (Flate/LZW), font handling, image decoding, and graphics path rendering, exercising a wide mix of string processing, typed array manipulation, and complex control flow.

This benchmark exercises a broad cross-section of engine capabilities simultaneously: typed array performance for binary data processing, string handling for text extraction, complex control flow with many branches for format parsing, and object allocation for document structure. The engine's overall balance across these different subsystems matters more than any single optimization, making it a good indicator of general-purpose performance.

Directory: Octane

File Size
pdfjs.js 1.5 MB

postcss-wtb

Processes CSS stylesheets using PostCSS, a tool for transforming CSS with plugins. Each iteration parses multiple real-world CSS files (Bootstrap, Foundation, Angular Material) into an AST, applies transformations, and serializes back to CSS text, testing string processing and tree manipulation.

PostCSS exercises the engine's string processing and regular expression performance heavily, as CSS parsing relies on regex-based tokenization for selectors, properties, and values. The plugin pipeline architecture creates chains of transformation functions that walk and modify the CSS AST, testing function call overhead and object property mutation performance. String concatenation during CSS serialization and the engine's optimization of template-literal-like string building patterns also contribute to the overall score.

Directory: web-tooling-benchmark

File Size
dist/postcss.bundle.js 1.2 MB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

prettier-wtb

Formats JavaScript source code using Prettier, an opinionated code formatter. Each iteration parses and re-prints multiple JavaScript files from the WTB data set, testing the performance of parsing, AST manipulation, and the Prettier printing algorithm (based on Wadler's "A prettier printer").

Prettier's document IR and line-fitting algorithm create deeply recursive data structures and perform extensive pattern matching on AST node types using switch statements and dynamic property access. The engine's optimization of recursive function calls (particularly tail-call-like patterns in the printer), string concatenation for output assembly, and the creation of many small intermediate "doc" IR objects are the primary performance drivers. Efficient garbage collection of the short-lived IR nodes produced during formatting is also important.

Directory: web-tooling-benchmark

File Size
dist/prettier.bundle.js 611.4 KB
benchmark.js (in dir)
(same third-party input files as acorn-wtb)

prismjs-startup-es5

The same Prism.js syntax highlighting workload as prismjs-startup-es6, but loading the ES5-transpiled bundle. This tests how the engine handles the older JavaScript patterns produced by ES5 transpilation compared to native ES6 syntax. This benchmark is not run by default.

The comparison between ES5 and ES6 variants reveals whether the engine's parser and JIT compiler are better optimized for modern or legacy JavaScript patterns. Differences in score typically come from the parser's handling of var vs let/const, function expressions vs arrow functions, and prototype chains vs native classes — and whether the JIT compiler can produce equally efficient code for both styles.

Directory: prismjs

File Size
benchmark.js (in dir)
dist/bundle.es5.min.js (preloaded) 48.0 KB
(same data/ sample files as es6 variant)
../utils/StartupBenchmark.js 4.1 KB

prismjs-startup-es6

Measures the startup performance of loading the Prism.js syntax highlighting library from its ES6 bundle and highlighting code samples. Each iteration evaluates the library via eval, then highlights sample code in 8 languages (C++, CSS, HTML, JavaScript, JSON, Markdown, Python, SQL, TypeScript), testing code compilation speed and regex-heavy syntax highlighting execution.

The benchmark combines startup-style testing (code compilation via eval) with regex-heavy execution (syntax highlighting is fundamentally regex-driven). Parser throughput and bytecode caching effectiveness determine the compilation portion, while the regex engine's performance on the diverse set of highlighting patterns (language grammars expressed as regex) determines the execution portion. The interplay between these two phases — and how their relative costs shift across iterations — is the distinctive aspect.

Directory: prismjs

File Size
benchmark.js (in dir)
dist/bundle.es6.min.js (preloaded) 47.9 KB
data/sample.cpp (preloaded) 836 B
data/sample.css (preloaded) 1.8 KB
data/sample.html (preloaded) 4.1 KB
data/sample.js (preloaded) 1.9 KB
data/sample.json (preloaded) 286 B
data/sample.md (preloaded) 209 B
data/sample.py (preloaded) 449 B
data/sample.sql (preloaded) 169 B
data/sample.ts (preloaded) 603 B
../utils/StartupBenchmark.js 4.1 KB

proxy-mobx

Tests the MobX reactive state management library's use of JavaScript Proxy objects for automatic dependency tracking. Each iteration creates observable state, computes derived values, and triggers reactive updates, stressing the engine's Proxy handler trap dispatch, property interception, and microtask-based reaction scheduling.

This benchmark is a direct test of the engine's Proxy implementation performance. The overhead of Proxy trap dispatch (get, set, has, ownKeys), the ability to inline or optimize through Proxy handlers, and the efficiency of WeakMap/Map lookups used internally by MobX for dependency tracking are the dominant factors. Engines where Proxy traps have high per-call overhead will be particularly penalized.

Directory: proxy

File Size
common.js 9.0 KB
mobx-bundle.js 51.3 KB
mobx-benchmark.js 2.2 KB

proxy-vue

Tests the Vue.js reactivity system's use of JavaScript Proxy objects for reactive state tracking. Each iteration creates reactive objects with computed properties and watchers, triggering dependency collection and update propagation through the Vue reactivity engine, exercising Proxy traps and effect scheduling.

Like proxy-mobx, this benchmark tests Proxy trap dispatch performance, but with Vue's different reactivity architecture. Vue's reactive system has a different pattern of Proxy usage — more focused on get/set traps with effect tracking — and the engine's optimization of these specific trap patterns, along with WeakMap performance for reactive mapping and the efficiency of Set operations for dependency tracking, determine the score.

Directory: proxy

File Size
common.js 9.0 KB
vue-bundle.js 125.8 KB
vue-benchmark.js 2.2 KB

quicksort-wasm

Sorts arrays using a quicksort algorithm compiled from C to WebAssembly. The benchmark measures WebAssembly execution of a classic sorting algorithm, testing Wasm branch-heavy code performance and comparison-driven data movement.

This benchmark tests the Wasm engine's handling of branch-heavy code with many conditional jumps (comparisons and partitioning). The efficiency of the Wasm compiler's branch lowering, the quality of its instruction selection for comparison-and-branch sequences, and the overhead of Wasm linear memory loads/stores for array element access are the primary factors.

Directory: wasm/quicksort

File Size
build/quicksort.js (Emscripten glue) 28.3 KB
benchmark.js (in dir)
build/quicksort.wasm (preloaded) 7.4 KB

raytrace

Renders a 3D scene with ray tracing using an object-oriented architecture. The benchmark constructs a scene with spheres, planes, and lights, then traces rays per-pixel computing intersections, reflections, shadows, and Phong shading. It stresses polymorphic call sites, floating-point math, and object-oriented patterns.

Performance hinges on the JIT compiler's ability to devirtualize and inline method calls through the shape/material class hierarchy, as the inner loop calls intersection and shading methods polymorphically across different geometry types. Efficient unboxed floating-point representation and the optimization of Math.sqrt and other math operations in the inner ray-intersection loop are also important.

Directory: Octane

File Size
raytrace.js 15.8 KB

raytrace-private-class-fields

Runs the same ray tracing scene as the Octane raytrace benchmark, but with the code refactored to use ES2022 private class fields (#field syntax) for all instance properties. This tests the engine's ability to optimize private field access, which involves different internal property lookup mechanisms than regular properties.

Private class fields use a fundamentally different access mechanism than regular properties — they are looked up by a per-class brand check rather than by property name. The engine's ability to compile private field accesses into efficient machine code (ideally as fast as a regular property access with a known offset), and to avoid the overhead of the brand-check specification semantics in the hot path, are the critical factors.

Directory: class-fields

File Size
raytrace-private-class-fields.js 17.7 KB

raytrace-public-class-fields

Runs the same ray tracing scene as the Octane raytrace benchmark, but with the code refactored to use ES2022 public class fields (field = value declarations in class bodies) instead of constructor-based property initialization. This tests the engine's optimization of the public class fields language feature.

The key engine aspect is the optimization of public class field initialization. Class fields are syntactically equivalent to assigning properties in the constructor, but engines may implement them via different internal paths (e.g., using [[Define]] semantics rather than [[Set]]). The benchmark reveals whether the engine can optimize class field initialization to be as fast as manual constructor assignment, and whether the resulting object shapes are as predictable to inline caches.

Directory: class-fields

File Size
raytrace-public-class-fields.js 16.6 KB

regexp-octane

Executes a large collection of regular expression operations derived from patterns and inputs recorded from 50 popular websites. The benchmark tests the engine's regex compiler and execution performance across a diverse set of real-world patterns including character classes, alternation, backreferences, and lookahead.

This is a direct test of the engine's regular expression implementation. The regex compiler's ability to generate efficient automata, the quality of regex-specific optimizations (fast literal prefix matching, character class optimization, backtracking reduction), and the runtime overhead of capture group extraction all affect the score. Since the patterns come from real websites, they test a realistic distribution of regex complexity.

Directory: Octane

File Size
regexp.js 126.7 KB

richards

Simulates an operating system task scheduler with four task types (idle, device I/O, handler, and worker) passing packets between them. Each iteration runs thousands of scheduling cycles, testing polymorphic dispatch, linked list manipulation, and object property access patterns.

This is a classic benchmark for testing property access optimization and inline caching. The scheduler's dispatch loop accesses properties on different task objects through a shared interface, and the engine's ability to build efficient inline caches for these polymorphic accesses — together with optimization of the linked-list packet queues — determines performance.

Directory: Octane

File Size
richards.js 15.8 KB

richards-wasm

Runs the Richards OS task scheduler benchmark compiled from C to WebAssembly, with a JavaScript wrapper that repeatedly calls into Wasm to process 200,000 scheduler tasks. The benchmark specifically stresses JS-to-Wasm call overhead by invoking the Wasm scheduleIter function in a tight loop, in addition to testing Wasm execution of the scheduling algorithm itself.

The distinguishing feature of this benchmark is its focus on JS-to-Wasm call boundary overhead. With 200,000 cross-boundary calls per iteration, the cost of each JS-to-Wasm transition (argument marshalling, stack switching, context setup) is amplified. Engines that can reduce or eliminate this boundary cost — for example by inlining Wasm calls into JS or using shared calling conventions — will gain a significant advantage.

Directory: wasm/richards

File Size
build/richards.js (Emscripten glue) 23.2 KB
benchmark.js (in dir)
build/richards.wasm (preloaded) 7.9 KB

segmentation

Performs image segmentation and statistical analysis using a Worker-based parallel computation model. The benchmark includes a statistics library for computing mean, median, standard deviation, and confidence intervals, and processes segmentation data across multiple async tasks, testing the engine's handling of Web Workers and async coordination patterns.

This benchmark tests the interaction between the engine's async task scheduling and Worker thread management. The efficiency of the Worker message-passing mechanism, the overhead of structured clone serialization for transferring segmentation data between Workers, and the main thread's Promise-based coordination of parallel Worker results are the primary engine factors.

Directory: worker

File Size
segmentation.js 112.7 KB
async-task.js (preloaded) 29.3 KB

source-map-wtb

Processes JavaScript source maps using the source-map library, which includes a WebAssembly-compiled VLQ decoder for fast mapping resolution. Each iteration parses .map files (Lodash, Underscore, Preact, source-map library maps) and resolves original source positions, testing both JavaScript and Wasm performance for source map operations.

This benchmark uniquely combines JavaScript and WebAssembly performance. The VLQ (Variable-Length Quantity) decoding of source map mappings is performed by a Wasm module, making Wasm compilation speed and the efficiency of JS-to-Wasm call boundaries important. On the JavaScript side, JSON parsing of the .map files (which can be large) and binary search over the decoded mapping arrays for position resolution exercise the engine's built-in JSON parser and typed array handling.

Directory: web-tooling-benchmark

File Size
dist/source-map.bundle.js 446.9 KB
benchmark.js (in dir)
(same third-party input files as acorn-wtb, including source-map/lib/mappings.wasm)

splay

Repeatedly inserts and removes nodes in a splay tree, a self-adjusting binary search tree. The benchmark allocates many short-lived tree nodes and performs tree rotations, stressing the garbage collector's ability to handle rapidly churning object graphs and testing the engine's performance on pointer-heavy data structure operations.

This benchmark is primarily a garbage collection stress test. The constant allocation and abandonment of tree nodes creates heavy GC pressure, and the engine's ability to efficiently collect short-lived objects (generational GC, nursery sizing, write barrier efficiency) is the dominant factor. The pointer-chasing access pattern of tree traversal also tests memory access latency and the engine's object layout decisions.

Directory: Octane

File Size
splay.js 11.4 KB

sqlite3-wasm

Runs the SQLite speedtest1 benchmark compiled to WebAssembly, executing a comprehensive suite of SQL operations including table creation, bulk inserts, indexed queries, transactions, and joins. The benchmark uses SQLite's in-memory VFS and tests the performance of a large, real-world C application (SQLite) running through the Wasm engine.

This is one of the largest and most complex Wasm benchmarks, testing the engine's ability to handle a substantial compiled C application. Wasm compilation speed matters for the first iteration. For execution, the key factors are Wasm linear memory performance (SQLite is memory-intensive for B-tree operations), the quality of code generation for the SQLite virtual machine's instruction dispatch loop, and the overhead of Emscripten's filesystem emulation layer.

Directory: sqlite3

File Size
benchmark.js (in dir)
build/jswasm/speedtest1.js (Emscripten glue) (in dir)
build/jswasm/speedtest1.wasm (preloaded) (in dir)
../utils/polyfills/fast-text-encoding/1.0.3/text.js 9.6 KB

stanford-crypto-aes

Encrypts and decrypts test data using the AES cipher implementation from the Stanford JavaScript Crypto Library (SJCL). The benchmark loads the full SJCL library and exercises AES encryption in various modes, testing bitwise operations, array manipulation, and cryptographic computation throughput.

Performance is driven by the engine's optimization of 32-bit integer bitwise operations (XOR, shift, rotate) and array lookups into fixed substitution tables (S-boxes). The JIT compiler's ability to keep intermediate values in integer registers without boxing, and to optimize the tight round-function loops of the AES cipher, are the critical factors.

Directory: SeaMonster

File Size
sjlc.js (Stanford JS Crypto Library) 28.2 KB
stanford-crypto-aes.js 457.8 KB

stanford-crypto-pbkdf2

Derives cryptographic keys using the PBKDF2 (Password-Based Key Derivation Function 2) algorithm from the Stanford JavaScript Crypto Library. Each iteration performs key derivation with multiple iterations and different salts, stressing iterative HMAC computation and the engine's ability to optimize tight cryptographic loops.

The engine's optimization of repeated HMAC-SHA256 invocations in a tight loop determines performance. Since PBKDF2 deliberately runs thousands of hash iterations, the throughput of the underlying SHA-256 implementation (bitwise operations, array access, integer arithmetic) is the dominant factor. Any per-iteration overhead in function calls or array allocation becomes amplified.

Directory: SeaMonster

File Size
sjlc.js (Stanford JS Crypto Library) 28.2 KB
stanford-crypto-pbkdf2.js 1.8 KB

stanford-crypto-sha256

Computes SHA-256 hashes iteratively using the Stanford JavaScript Crypto Library, running 4500 rounds of hashing per iteration. This focuses purely on the performance of the SHA-256 compression function, stressing 32-bit integer arithmetic and bitwise operations.

This is one of the purest integer computation benchmarks in the suite. The SHA-256 compression function consists entirely of 32-bit bitwise operations (AND, OR, XOR, rotations) and modular addition. The engine's ability to represent values as unboxed 32-bit integers and to generate efficient machine code for the compression function's 64-round loop is essentially the only factor that matters.

Directory: SeaMonster

File Size
sjlc.js (Stanford JS Crypto Library) 28.2 KB
stanford-crypto-sha256.js 1.7 KB

sync-fs

Simulates synchronous file system operations using generator functions. Each iteration builds and manipulates a virtual file system tree through synchronous generator-based iteration, testing the engine's optimization of generator function suspension/resumption and for...of iteration over generator objects.

This benchmark tests the engine's generator function implementation. The overhead of generator suspension (saving stack frame state at yield) and resumption (restoring state on .next()), and the efficiency of the for...of protocol over generator objects (including the iterator result object allocation {value, done}) are the critical engine factors. Engines that can optimize away iterator result allocations or inline the generator state machine will perform better.

Directory: generators

File Size
sync-file-system.js 8.8 KB

tfjs-wasm

Loads and runs inference on multiple TensorFlow.js machine learning models using the WebAssembly backend: MobileNet v1 and v3 (image classification), COCO-SSD (object detection), and Universal Sentence Encoder (text embeddings). Each iteration loads model weights from JavaScript-embedded data and performs prediction, testing the TensorFlow.js + Wasm computation pipeline. This benchmark is not run by default.

This benchmark tests both JavaScript and Wasm performance. The JS side involves parsing very large model weight files embedded as JavaScript (up to 25 MB each), stressing the parser and memory allocator. The Wasm side tests the TensorFlow.js Wasm backend's execution of neural network operations (convolution, matrix multiply, activation). The Wasm engine's compilation speed and execution throughput for the 311 KB backend module are the primary Wasm factors.

Directory: wasm

File Size
tfjs-model-helpers.js 4.2 KB
tfjs-model-mobilenet-v3.js 18.9 MB
tfjs-model-mobilenet-v1.js 22.7 MB
tfjs-model-coco-ssd.js 24.8 MB
tfjs-model-use.js 8.5 MB
tfjs-model-use-vocab.js 189.5 KB
tfjs-bundle.js (TensorFlow.js library) 18.4 MB
tfjs.js 7.0 KB
tfjs-benchmark.js 1.8 KB
tfjs-backend-wasm.wasm (preloaded) 311.1 KB

tfjs-wasm-simd

The same TensorFlow.js machine learning workload as tfjs-wasm, but using a WebAssembly module compiled with SIMD (Single Instruction, Multiple Data) instructions for accelerated tensor operations. This tests the engine's support for and optimization of Wasm SIMD extensions. This benchmark is not run by default.

The key differentiator from tfjs-wasm is the engine's Wasm SIMD implementation quality. The speed of SIMD instructions (v128 loads/stores, f32x4 arithmetic, i8x16 operations) and the Wasm compiler's ability to effectively vectorize and schedule SIMD operations determine how much speedup the SIMD variant achieves over the scalar version.

Directory: wasm

File Size
(same JS files as tfjs-wasm) (same)
tfjs-backend-wasm-simd.wasm (preloaded) 424.6 KB

threejs

Simulates a particle system using the Three.js 3D graphics library with a mock WebGL context. The benchmark creates 8000 particles with circle geometries and outline meshes, then animates them with velocity-based movement and boundary collision, exercising Three.js's scene graph, matrix transforms, geometry processing, and render loop — all without actual GPU rendering.

Performance is driven by the engine's optimization of the Three.js framework's object-oriented patterns — many small method calls through a deep class hierarchy (Object3D, Mesh, BufferGeometry, Material, etc.), frequent property access on objects with complex shapes, and matrix math using Float32Array typed arrays. The engine's ability to inline small methods across the class hierarchy and to optimize Float32Array operations in the math library are the key factors.

Directory: threejs

File Size
three.js (Three.js library) 1.2 MB
benchmark.js 6.5 KB

transformersjs-bert-wasm

Runs sentiment analysis using a DistilBERT transformer model via the Transformers.js library backed by the ONNX Runtime WebAssembly engine. Each iteration tokenizes input sentences and runs the quantized (uint8) BERT model to classify them as positive or negative, testing the end-to-end ML inference pipeline including tokenization, Wasm-based tensor operations, and model execution.

This benchmark combines JavaScript execution (Transformers.js tokenization and pipeline orchestration) with heavy Wasm computation (ONNX Runtime tensor operations). The Wasm engine's SIMD instruction support and execution efficiency dominate the model inference time. Wasm compilation speed matters for the first iteration due to the large 11 MB ONNX Runtime module. The JS-to-Wasm boundary overhead for the many tensor operation calls also contributes.

Directory: transformersjs

File Size
benchmark.js (in dir)
task-bert.js (in dir)
build/transformers.js (preloaded) 2.2 MB
build/onnxruntime-web/ort-wasm-simd-threaded.mjs (preloaded) 20.9 KB
build/onnxruntime-web/ort-wasm-simd-threaded.wasm (preloaded) 11.1 MB
build/models/Xenova/distilbert-.../onnx/model_uint8.onnx (preloaded) 67.4 MB
build/models/Xenova/distilbert-.../config.json (preloaded) 735 B
build/models/Xenova/distilbert-.../tokenizer.json (preloaded) 711.4 KB
build/models/Xenova/distilbert-.../tokenizer_config.json (preloaded) (small)
../utils/polyfills/fast-text-encoding/1.0.3/text.js 9.6 KB

transformersjs-whisper-wasm

Runs automatic speech recognition using the Whisper Tiny model via the Transformers.js library with the ONNX Runtime WebAssembly backend. Each iteration processes a raw audio recording of JFK's inaugural address through the encoder and decoder models (quantized to q8) to produce a text transcription, testing end-to-end audio ML inference. This benchmark is not run by default.

Performance is dominated by the same factors as transformersjs-bert-wasm — Wasm SIMD execution for the ONNX Runtime's tensor math, compilation speed for the large Wasm module, and JS-to-Wasm interop overhead. The Whisper model's autoregressive decoder also exercises Wasm memory management more heavily, as it processes the audio data through multiple sequential inference passes.

Directory: transformersjs

File Size
benchmark.js (in dir)
task-whisper.js (in dir)
build/transformers.js (preloaded) 2.2 MB
build/onnxruntime-web/ort-wasm-simd-threaded.mjs (preloaded) 20.9 KB
build/onnxruntime-web/ort-wasm-simd-threaded.wasm (preloaded) 11.1 MB
build/models/Xenova/whisper-tiny.en/onnx/encoder_model_quantized.onnx (preloaded) 10.1 MB
build/models/Xenova/whisper-tiny.en/onnx/decoder_model_merged_quantized.onnx (preloaded) 30.7 MB
build/models/Xenova/whisper-tiny.en/config.json (preloaded) 2.2 KB
build/models/Xenova/whisper-tiny.en/tokenizer.json (preloaded) 2.1 MB
build/models/Xenova/whisper-tiny.en/tokenizer_config.json (preloaded) (small)
build/models/Xenova/whisper-tiny.en/preprocessor_config.json (preloaded) (small)
build/models/Xenova/whisper-tiny.en/generation_config.json (preloaded) (small)
build/inputs/jfk.raw (preloaded, audio data) 272.0 KB
../utils/polyfills/fast-text-encoding/1.0.3/text.js 9.6 KB

tsf-wasm

Exercises the TSF (Typed Stream Format) serialization library compiled from C to WebAssembly. Each iteration runs 50 internal iterations of data serialization and deserialization operations, testing the Wasm engine's handling of structured data processing, memory allocation, and function call overhead within a compiled C application.

This benchmark tests the Wasm engine's performance on a mixed workload of memory allocation (via Emscripten's malloc), structured data access through Wasm linear memory, and internal Wasm function calls. The engine's optimization of Wasm call instructions, the efficiency of its memory bounds checking, and the quality of code generation for the data marshalling operations are the key factors.

Directory: wasm/TSF

File Size
build/tsf.js (Emscripten glue) 116.4 KB
benchmark.js (in dir)
build/tsf.wasm (preloaded) 144.1 KB

typescript-lib

Compiles a real TypeScript project (the immer library) using a bundled copy of the TypeScript compiler. Each iteration runs the full compilation pipeline — scanning, parsing, binding, type checking, and JavaScript emit — on a set of TypeScript source files loaded from JSON, testing the engine's performance on a large, complex, real-world application.

As a large, real-world application, this benchmark tests the engine comprehensively. String handling performance (for source text scanning and identifier interning), hash map efficiency (for symbol table lookups and type maps), and the JIT compiler's ability to optimize a large codebase where many functions individually may not reach the optimization threshold are the dominant factors. The 3.9 MB of source file data loaded from JSON also tests JSON parsing speed.

Directory: TypeScript

File Size
src/mock/sys.js 680 B
dist/bundle.js (TypeScript compiler) 4.7 MB
benchmark.js (in dir)
src/gen/immer-tiny/tsconfig.json (preloaded) 456 B
src/gen/immer-tiny/files.json (preloaded) 3.9 MB

typescript-octane

Compiles a TypeScript input file using the TypeScript compiler, exercising the full compilation pipeline including scanning, parsing, type checking, and JavaScript code emission. This stresses complex control flow, large switch statements, string operations, and hash table lookups.

This benchmark represents a large, complex, real-world application and tests the engine broadly. Key factors include string interning and comparison performance (used extensively in symbol tables), the efficiency of hash map (object/Map) lookups for type resolution, optimization of large switch statements in the scanner and parser, and the ability of the JIT to handle a large code base with many functions that individually may not be hot enough to optimize aggressively.

Directory: Octane

File Size
typescript-compiler.js 1.2 MB
typescript-input.js 1.3 MB
typescript.js 6.2 KB

validatorjs

Runs the validator.js library, a comprehensive string validation and sanitization toolkit. The benchmark exercises hundreds of validation functions including email, URL, IP address, credit card, UUID, and other format validators, heavily stressing the regex engine with a diverse set of real-world validation patterns.

This benchmark is dominated by regular expression performance across a wide variety of pattern complexities — from simple character class checks to complex patterns with alternation, lookahead, and backreferences. The regex compiler's ability to select optimal matching strategies for different pattern types, and the overhead of regex object creation and match result extraction, determine the score.

Directory: validatorjs

File Size
dist/bundle.es6.min.js 344.4 KB
benchmark.js (in parent dir)

web-ssr

Measures the performance of server-side rendering a React application to HTML strings. Each iteration evaluates the full bundled React application via eval, then calls renderToString to produce HTML markup, testing code compilation speed and the execution overhead of React's server-side rendering pipeline including virtual DOM construction and HTML serialization.

The score is split between code compilation (parsing and compiling the 756 KB React bundle via eval) and execution (running React's renderToString). On the compilation side, parser throughput and bytecode caching are key. On the execution side, the engine's optimization of React's virtual DOM diffing (many small object allocations, property comparisons) and string concatenation for HTML output generation are the main factors.

Directory: web-ssr

File Size
benchmark.js (in dir)
dist/bundle.min.js (preloaded) 755.7 KB
../utils/StartupBenchmark.js 4.1 KB

zlib-wasm

Compresses and decompresses data using the zlib library compiled from C to WebAssembly. Each iteration writes its own Wasm binary as input, then performs 10 rounds of compression and decompression through the Wasm-compiled zlib, verifying that the roundtripped data matches the original. This tests the Wasm engine's performance on a real-world data compression workload.

This benchmark tests the Wasm engine's performance on a classic systems programming workload — zlib's deflate algorithm involves hash table lookups, string matching, Huffman coding, and sequential memory access. The Wasm compiler's optimization of the hash table probe loop, the efficiency of linear memory access for the sliding window, and Wasm function call overhead within the compression pipeline are the key factors.

Directory: wasm/zlib

File Size
build/zlib.js (Emscripten glue) 115.5 KB
benchmark.js (in dir)
build/zlib.wasm (preloaded) 64.9 KB

Parser-Sensitive Benchmarks

The following benchmarks are significantly affected by JavaScript parser performance. They fall into two categories: benchmarks that stress the engine's own parser through code loading and eval, and benchmarks whose workload is itself a JavaScript parser or compiler running in JavaScript.

Engine parser (code loading and eval)

These benchmarks measure or heavily involve the engine's built-in JavaScript parser and bytecode compiler, typically by loading or evaluating large JavaScript source texts.

  • first-inspector-code-load and multi-inspector-code-load — Both parse the same 2.1 MB minified WebKit Web Inspector frontend (inspector-payload-minified.js). The payload is a minified concatenation of the Inspector's source files, compressed from 2.6 MB / 23,855 lines down to 61 lines, with the bulk of the code on a single 2 MB line. The code is a mix of ES6 class syntax and traditional namespace patterns organized under a global WebInspector object — no ES modules. It contains 466 class declarations with 462 extends inheritance chains and 438 super() calls, making it one of the most class-hierarchy-heavy payloads in the suite. There are 1,043 function keywords, 462 arrow functions, and heavy use of getters (1,542) and setters (355). Variable declarations mix styles: 2,825 let, 2,341 var, and only 123 const. The code has 26,279 this. references, 1,952 new expressions, and 180 static members. There are virtually no comments (7 block comments, all in the license header), 156 backtick template literals, and no async/await. The first-inspector-code-load variant wraps the payload in a uniquely-named function on each iteration to defeat bytecode caching, while multi-inspector-code-load cycles through 20 function names so the engine can cache and reuse compiled bytecode.

  • octane-code-load — Evaluates two minified ES5 payloads embedded as string literals: Google Closure Library base.js (~8 KB) and jQuery 1.7.2 (~97 KB). Both are aggressively minified with single-character variable names and all whitespace stripped. The code is purely ES5 — no classes, arrow functions, let/const, template literals, or async/await. Closure Library uses a namespace pattern (goog.provide, goog.require) with ~50 anonymous function expressions and ~31 var declarations. jQuery is substantially larger with ~437 anonymous function expressions, ~277 var declarations, ~457 ternary operators, ~129 for loops, ~372 if statements, and ~663 array accesses. Both use IIFE (Immediately Invoked Function Expression) patterns — functions that are defined and called in a single expression, such as (function(a,b){ ... })(window,document) — to create private scopes and avoid polluting the global namespace. There are essentially no comments in either payload. The minified code is dense with chained expressions and prototype-based OOP — a parser stress test for legacy JavaScript patterns.

  • mobx-startup — Evaluates a 72 KB minified MobX bundle (bundle.es6.min.js) via eval. The code is a Webpack-bundled CommonJS module wrapped in an arrow-function IIFE. It is heavily minified with single-character variable names. Despite being labeled ES6, the minified output is dominated by function keywords (459) and var declarations (314), with only 17 arrow functions, 17 const, 5 let, and 4 class declarations. There are no async/await or super calls. The payload contains 464 strategically placed /*ThouShaltNotCache*/ block comments (roughly one every 155 bytes). Before each eval, the StartupBenchmark harness uses replaceAll to substitute every occurrence of \n/*ThouShaltNotCache*/\n (the comment with its surrounding newlines) with a short block comment containing an iteration-dependent numeric ID — for example /*0*/, /*8*/, or /*24*/. The replacement happens on the source string before it is passed to eval, so the engine's lexer never sees the original ThouShaltNotCache text; it sees the shorter replacement comments (5–7 characters instead of 23). This makes each group of iterations produce a textually distinct source string, preventing the engine from reusing cached bytecode across groups. The code uses Symbol (25 occurrences) and features 505 this. references. There are 20 backtick template literals and 2 yield expressions.

  • jsdom-d3-startup — Parses a 3.6 MB minified Webpack bundle (bundle.min.js) containing jsdom, D3.js, and topojson. This is the second-largest JavaScript payload in the suite. The code is a modern ES6-heavy bundle: 3,546 arrow functions, 3,543 function keywords, 7,408 const, 1,897 let, and 1,602 var declarations. It features 379 class declarations with 64 super() calls, 25 async functions, 30 yield expressions, and 2,311 backtick template literals. There are 1,095 try blocks, 5,014 new expressions, and 1,615 .prototype references. The bundle includes extensive Node.js polyfills (path, stream, buffer, url). It contains 10,031 /*ThouShaltNotCache*/ comments for cache busting — roughly one every 355 bytes. The code exercises a very broad set of parser productions due to the diversity of bundled libraries.

  • web-ssr — Evaluates a 756 KB minified React SSR bundle (bundle.min.js). The code is almost entirely ES5-style despite being a modern React application: 684 function keywords, 865 var declarations, and only 15 arrow functions, 1 class, zero let/const, and no async/await. This is because the Webpack/Babel build transpiles most modern syntax to ES5. The bundle uses Symbol (84 occurrences) for React's internal type markers (Symbol.for("react.element")), and has 40 .prototype references. There are 652 /*ThouShaltNotCache*/ comments for cache busting, 12 backtick template literals, and no super or yield. The payload includes React, ReactDOM server renderer, and a wine-list application with 100 data objects and ~20 components.

  • babylonjs-startup-es5 — Parses an 11.6 MB minified ES5 bundle, the largest JavaScript payload in the suite. The code is the full Babylon.js 3D engine transpiled from ES6 to ES5 via Babel. It contains 49,740 function keywords, 33,422 var declarations, and 11,304 .prototype references — the hallmarks of transpiled class hierarchies. There are 2,024 Object.defineProperty calls and 1,402 Object.create calls used to emulate class semantics. Modern syntax is almost absent: only 3 class keywords, 2 arrow functions, and 1 async. The payload has 64,991 this. references and 8,075 new expressions. There are 45,622 /*ThouShaltNotCache*/ comments (one every ~255 bytes), which dominate the comment content — virtually no documentation comments survive minification.

  • babylonjs-startup-es6 — Parses an 8.9 MB minified ES6 bundle of the same Babylon.js engine, 23% smaller than the ES5 variant due to the elimination of transpilation boilerplate. This version uses native ES6 syntax throughout: 1,539 class declarations with 900 extends and 864 super() calls, 8,353 arrow functions, 13,324 const, 4,377 let, and only 5,132 var. It has 294 async functions, 683 await expressions, 37 yield expressions, and 3,888 backtick template literals. The .prototype count drops to 4,356 (from 11,304 in ES5) and Object.defineProperty drops to 262 (from 2,024). There are 78,578 this. references, 972 super. member accesses, and 25,994 /*ThouShaltNotCache*/ comments. Comparing this with the ES5 variant reveals how much the parser benefits (or suffers) from native class syntax versus transpiled prototype chains.

  • prismjs-startup-es6 and prismjs-startup-es5 — Both evaluate small (~48 KB) minified Prism.js syntax-highlighting bundles via eval. The ES6 variant has 30 arrow functions and 75 function keywords; the ES5 variant has 12 arrow functions and 93 function keywords (the difference reflects transpilation of some arrow functions to regular functions). Both have 103 var declarations, 2 const, zero let, and zero class declarations. The most distinctive feature is the heavy use of regex literals: 458 regex patterns in each variant, used for language grammar definitions. There are 63 backtick template literals, 7 yield expressions, and 71 /*ThouShaltNotCache*/ comments. The difference between ES5 and ES6 scores is largely attributable to the parser's handling of shorthand property syntax ({content, lang} in ES6 vs. {content:content, lang:lang} in ES5) and arrow-vs-function expression parsing.

JavaScript-implemented parsers and compilers

These benchmarks run a JavaScript parser, compiler, or transpiler implemented in JavaScript as their workload. While the engine's own parser is not the bottleneck, the execution of the parser code exercises engine capabilities (string processing, object allocation, function dispatch) that are closely related to parser performance.

  • Babylon — Runs the Babylon parser on multiple large source files, testing string processing and AST construction.
  • typescript-octane — Runs the TypeScript compiler including its scanner and parser phases.
  • typescript-lib — Compiles a real TypeScript project using the full TypeScript compiler pipeline (scanning, parsing, type checking, emit).
  • acorn-wtb — Parses multiple real-world JavaScript libraries using the Acorn parser.
  • babel-wtb — Transpiles JavaScript using the Babel compiler, which includes parsing input files.
  • babel-minify-wtb — Minifies JavaScript using babel-minify, which parses input files before applying transformations.
  • babylon-wtb — Parses JavaScript using the Babylon parser with JSX and TypeScript extension support.
  • espree-wtb — Parses JavaScript using Espree (ESLint's parser).
  • esprima-next-wtb — Parses JavaScript using esprima-next.
  • prettier-wtb — Formats JavaScript using Prettier, which includes parsing input files.
  • lebab-wtb — Transforms ES5 to ES2015+ using Lebab, which includes parsing input files.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment