Each library runs the same integer workload, one library at a time, so
they do not contend for the same event-loop slice. Times are wall
clock in this browser. After each timed op, the result is checked
once against native BigInt (not included in the time).
A mismatch marks the cell fail. Divide and mod use a
double-width dividend; modPow uses a 256-bit exponent against a
full-width odd modulus. big-integer wraps native
BigInt when the engine provides it.
Idle. Press run to start.
Recorded Node 22 run
jsbn does not lose the heavier run
Same adapters as the live suite above, recorded in Node 22 / V8. 2048-bit operands × 8000 iterations. Divide and mod use a double-width dividend; modPow uses a 256-bit exponent against a full-width odd modulus (800 rounds). These times are not the in-browser result — run the button if you want this tab’s clock.
7 / 8
Fastest in the row
8 / 8
Wins vs bn.js
1.02×
add vs big-integer (only loss)
2048-bit × 8000 — mid-cost ops
Wall time in milliseconds. Each cluster is scaled to the slowest bar in that cluster. bignumber.js omitted so the jsbn / big-integer / bn.js gap is readable; it is 20–50× slower on multiply, divide, and mod. Source: Node 22, 17 Aug 2026.
2048-bit × 8000 — heavy ops
Each cluster is scaled to the slowest bar in that cluster. gcd is 8000 iterations; modPow is 800 rounds of 2048-bit base/modulus with a 256-bit exponent. toString of the 4096-bit dividend is in the table — bn.js at 8.5 s would flatten the chart. Source: Node 22, 17 Aug 2026.
2048-bit × 8000 results
Bold green is fastest in the row. Last column is jsbn / fastest. Times in ms. bignumber.js gcd was not run (a JS Euclidean loop on Decimal objects; tens of seconds at this size).
Why the original 800-iter ranking lied
big-integer is a native BigInt wrapper in
this engine, so it was never a like-for-like JS big-integer
implementation. jsbn’s public arithmetic now uses the same engine
primitive and only materializes the classic 28-bit digit array when
something like toByteArray needs it — which is why add
and multiply land within a few percent of big-integer, while gcd and
modPow pull ahead (Euclid and windowed exp on raw
BigInt, versus their method-call loops). bn.js still
wins nothing here: it is a JS limb library. bignumber.js is a
general decimal library, fast-ish at toString until you cache the
decimal from parse, and slow at integer multiply and divide.