[moose-code]

Stacked on #1732 (moose/subgraph-compat-fixes). Five perf commits, plus merges of #1732's head up to 787e304 (the only conflict was an import line). Measured on 9918a53.

What it changes

commit	change
count the sync bridge's replay rounds	ENVIO_SUBGRAPH_SYNC_STATS=1 prints SGSTATS {json} with runs, rounds and a rounds histogram for preload and for execute. It's off by default, and when off it costs one branch.
hash crypto.keccak256 natively	Adds a napi subgraphKeccak256 (alloy) to replace viem's JS keccak and its hex round trip. A call drops from 6.4 µs to 1.1 µs. ENS hashes on every NewOwner, once per replay round, and keccak was 15% of its CPU.
let preload read past a miss; suspend without building an Error	In preload, a miss now answers "absent" and the round keeps going, so independent reads land in the same batch. That's bounded at 32 reads per round, and an effect never runs on a speculated value. Execute still suspends on every miss. Separately, throw(Suspend) used to build an Error with a stack trace on every miss; it now throws one prebuilt value.
hold the mapping scope in a variable, not an AsyncLocalStorage	Mapping rounds are synchronous. A module's top level keeps the scope until its import settles. On Node 22 this also removes the promise hooks that ran on every promise (about 4% of CPU).
convert rows and event parameters with less work per call	The per-entity layout is cached, so we no longer build three new Set per load and per save. Bigint columns are no longer re-parsed. TypedMap.getEntry no longer allocates a closure. Each event parameter is decoded on first read instead of all at once.

Measurements

Paired A/B runs: the baseline (9918a53 plus the stats commit) and this branch index the same fixed window at the same time, so load from the shared box hits both equally. Envio 3.14 subgraph mode, Postgres, nice -n 10.

subgraph, window	baseline	this branch	speedup
ENS, blocks 0→5,000,000, 267,661 events (handler-bound)	3,003 ev/s, 109.3 s CPU	3,827 ev/s, 87.9 s CPU	x1.27 events/s, x1.24 CPU
Polymarket OI, 50.6M→61M from a snapshot, 4,033,124 events (solo, back to back)	26,057 ev/s, 161.2 s CPU	27,795 ev/s, 134.7 s CPU	x1.07 events/s (this window is now HyperSync-bound), x1.20 CPU, x1.27 handler time

Per commit (ENS, cumulative): keccak x1.14 → + speculative preload x1.13 (within noise; rounds don't change on ENS) → + sync scope x1.22 → + conversions x1.25.

Correctness: after every pair I compared each entity table row for row (EXCEPT ALL both ways on the row's text form). Every comparison had 0 differing rows: ENS (27 tables, e.g. Domain 201,286 and NewOwner 226,531 rows) and Polymarket (4 tables).

Tests: on the merged head (787e304 merged in, addon rebuilt), vitest run test/Subgraph test/SyncContext passes 64 of 64 files and 185 of 185 tests. There are two new SyncContext cases: independent preload reads batch into one round, and an effect is only ever called with stored values. pnpm check-graph-ts is clean.

The full write-up (profiles, replay-round counts, what's left) is in spec/PERF.md in the hackathon workspace. The biggest remaining items:

• performance.now() handler timing costs 11.5% of Polymarket CPU on a box with an HPET clocksource.
• ENS execute-phase misses: preload can't see the batch's own writes, so Resolver.load costs a DB round trip on 6.5% of events.
• ENSRainbow lookups go through undici fetch.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[DZakh]

Merged