Skip to content

Use bigint#23

Open
peachbits wants to merge 6 commits into
masterfrom
bigint
Open

Use bigint#23
peachbits wants to merge 6 commits into
masterfrom
bigint

Conversation

@peachbits

@peachbits peachbits commented May 19, 2026

Copy link
Copy Markdown
Contributor

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

  • Yes
  • No

Dependencies

none

Description

Replaces the bn.js dependency with native BigInt, and removes a redundant-normalization hot spot in floatShifts.

What changed

  • Arithmetic and comparisons use native BigInt through a parseBigInt helper that handles signed hex (-0x100), which BigInt() rejects. The bn.js runtime dependency is dropped.
  • floatShifts no longer re-normalizes its operands. isHex was re-running toBns on already-normalized strings (about 4 toBns calls per operation); it now uses a string-only isHexStr (one regex, no toLowerCase allocations). toBns runs the scientific-notation regex only when the input contains e, and validate checks for duplicate ./- without split() allocations.
  • Requires Node >= 10.4 and bumps the TypeScript target to ES2020 (native BigInt). Version 5.0.0.

Performance

320k mixed operations (add/sub/mul, div with precision, comparisons, toFixed, hex), measured on the React Native Hermes VM and on V8 (the plugin WebView engine class). Results are identical (checksum verified).

build Hermes V8
published 4.2.3 3.4 s 341 ms
this PR 2.0 s 162 ms

About 1.7x faster on Hermes and 2.1x faster on V8, with one fewer dependency. The two wins are independent: native BigInt is faster than bn.js for parse, arithmetic, and toString on both engines (bn.js is pure-JS 26-bit-word math, BigInt runs in the engine), and the leaner floatShifts removes work the published build was already avoiding but the repo source was not.


Note

High Risk
Core numeric behavior now depends on native BigInt and integer division semantics instead of bn.js, which is a breaking major bump for a library used in money-related string math.

Overview
5.0.0 drops the bn.js runtime dependency and routes all arithmetic and comparisons through native BigInt, with a parseBigInt helper so signed hex like -0x100 still parses. Public API shape is unchanged; Node >= 10.4 and TypeScript ES2020 are now required.

Hot-path work is trimmed: floatShifts uses string-only isHexStr instead of re-running toBns inside hex detection; toBns only runs the scientific-notation regex when the input contains e; validate avoids split allocations. precisionAdjust compares rounding digits in-place instead of calling gte/gt, and trimEnd is a single index scan instead of multiple regex passes.

Tooling is narrowed to TypeScript-only lint (JSX/React/Babel ESLint paths and plugins removed), legacy .babelrc and CircleCI config deleted, and dev dependencies refreshed (TypeScript 5, pinned ESLint stack).

Reviewed by Cursor Bugbot for commit 0061c39. Bugbot is set up for automated code reviews on this repo. Configure here.

@peachbits peachbits force-pushed the bigint branch 2 times, most recently from 4d4f1fc to bbb0f18 Compare May 20, 2026 19:37
peachbits and others added 5 commits June 15, 2026 22:35
The BN suffix was a leftover from the bn.js library.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
floatShifts normalized each operand with toBns, then isHex re-ran toBns on
the already-normalized strings (~4 toBns calls per op). Replace isHex with a
string-only isHexStr that skips toBns and uses a single regex instead of up to
six toLowerCase().includes() allocations. Also gate the scientific-notation
regex behind an 'e' check and drop validate's split() allocations.

Correctness unchanged (195 tests pass); roughly halves core operation cost.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
precisionAdjust (floor/ceil/round) routed single-digit rounding checks through
the full public gte/gt API (each a floatShifts + parse round-trip). Compare the
rounding digit directly and test the remainder with a regex instead. trimEnd ran
up to four regex passes per call; rewrite it as one index scan.

Correctness unchanged (195 tests pass); about 1.6x faster on rounding-heavy and
decimal-heavy workloads.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant