philihp / pcg / 26031894998

100%

push

github

perf: move scheme→increment dispatch to the PCG config (#331)

* perf: move scheme→increment dispatch to the PCG config

Replace the inline ternary in nextState and the per-call 3-closure
incrementers object in stepStateImpl with a single getIncrement(pcg)
function stored on PCGConfig. Each variant supplies its own dispatch,
keeping all three schemes (SETSEQ, ONESEQ, MCG) intact.

Benchmarked vs origin/main:
- stepState(1_000_000): 5269 → 4468 ns/op (~15% faster)
- nextState / randomInt / randomList: noise (~3%)
- JSON round-trip: unchanged

The stepState win comes from dropping the per-call closure object
allocation. nextState was already inlined as a ternary so it doesn't
move much.

Also tried caching toBigInt(pcg.state) and toBigInt(pcg.streamId) via a
WeakMap side-table; on V8 the map ops cost roughly as much as the
BigInt allocations they replace, so it regressed nextState by ~2×.
A non-enumerable property cache would have been faster but breaks
serialize.test.ts's toStrictEqual (Jest compares own non-enumerable
and symbol keys). No cache shipped.

https://claude.ai/code/session_01PYpJLhJYgJWZWzH8xjRFte

* refactor: dispatch increment via Record<StreamScheme, SchemeFn>

Replace the chained if/else in createPcg32's getIncrement with a hash
lookup on a Record keyed by StreamScheme, matching the original shape
of the incrementers object that used to be allocated inside
stepStateImpl on every call.

The Record now lives on PCGConfig (allocated once per variant), and
both nextState and stepStateImpl dispatch via
`config.incrementers[pcg.streamScheme](pcg)`.

SchemeFn updated to take pcg so the SETSEQ branch can read streamId.

Benchmarks unchanged from the prior if/else version — V8 inline-caches
the property access:
- nextState: 424 ns/op (was 423)
- stepState(1_000_000): 4467 ns/op (was 4468)

https://claude.ai/code/session_01PYpJLhJYgJWZWzH8xjRFte

---------

Co-authored-by: Claude <noreply@anthropic.com>

21 of 30 branches covered (70.0%)

Branch coverage included in aggregate %.

6 of 6 new or added lines in 2 files covered. (100.0%)

102 of 106 relevant lines covered (96.23%)

13041.38 hits per line