Overview
Runs two JavaScript snippets side by side against the same iteration count and reports ops per second for each, with a winner badge and the percentage gap. Both snippets are compiled from their source text, warmed up before timing, and measured with performance.now in your current browser tab. Results depend on the machine and engine you are running, which is exactly the point: it is a comparison, not a universal ranking.
How It Works
Paste snippet A into the left editor and snippet B into the right one. Set the iteration count, 10,000 by default, and press Run Performance Comparison. The runner first executes each snippet 50 times as warmup, then times the iterations of A, then of B, converting elapsed time into ops per second. The faster side gets a highlighted border and a percentage figure. Errors in either snippet surface as an alert with the thrown message instead of a nonsense score.
Step-by-Step Usage Guide
- Paste the two code variants you want to compare into the A and B editors.
- Choose an iteration count high enough that each run takes tens of milliseconds at least.
- Click Run Performance Comparison and wait for the ops-per-second cards.
- Rerun two or three times and only trust gaps that appear consistently.
Technical Specifications & Standards
The timing model is deliberately simple: one timed loop per snippet, one warmup pass, ops per second computed as iterations divided by elapsed seconds. That simplicity has consequences you should respect when reading the numbers. V8 and other engines compile hot functions progressively, so the 50-run warmup absorbs the worst interpreter-to-JIT transition but cannot guarantee the optimizing compiler has settled; results for tiny functions can still drift between runs. Snippet A finishes its entire timed loop before snippet B starts, so background activity, GC pauses, or thermal throttling during one window skews that side rather than both equally; benchmarks that interleave A and B rounds are more robust to this. The snippets also run as bare scripts compiled with new Function, so top-level declarations persist as globals across iterations, and a snippet that leaks state, such as appending to an outer array, will slow itself down cumulatively. The tool's catalog entry mentions statistical confidence intervals, but the implementation reports a single point estimate per side; treat differences under roughly 10 percent as noise unless reruns repeat them.
Targeted Use Cases
- Choosing between string concatenation and array join in a hot loop.
- Checking whether a lookup table really beats a chain of conditionals in your browser.
- Comparing Date.now against performance.now overhead for a timing-sensitive feature.
- Teaching or demonstrating JIT warmup effects with before-and-after numbers.
Notes & Gotchas
- Rerun the benchmark several times; a single measurement in a JIT-compiled language is an anecdote.
- Make each snippet do enough work that loop overhead is not the dominant cost.
- Keep side effects symmetrical: if A mutates shared state, B should too, or the comparison is invalid.
- Close heavy tabs and avoid moving the window during the run; both pollute the timing window.
Frequently Asked Questions
Why do my results change between runs?
JavaScript engines compile and optimize code as it gets hot, and garbage collection and OS scheduling inject pauses. The tool warms each snippet up with 50 untimed runs, but residual variance is normal. Trust repeated differences, not single runs.
Does the tool report confidence intervals?
No. It reports one ops-per-second figure per snippet plus a percentage difference. The mention of statistical intervals is aspirational; the implementation gives a point estimate per side.
Can I benchmark async code like promises?
Not meaningfully. The runner invokes each snippet synchronously and times only the loop, so an async snippet returns immediately after scheduling work and the measurement reflects scheduling, not execution.
Why did snippet A run before snippet B?
The implementation times A fully, then B. Background events during one window affect only that side, which is one more reason to rerun and compare across several runs.