test: benchmark sponge absorption across bb transports

[vezenovm]

Opt-in sponge benchmark stacked on #195. Benchmark-only changes; no production or recurring CI changes.

Batching versus transport

SHM does not make batching redundant: #195 still improves sync SHM performance by 1.83–2.43× for 30+ fields. These results support #195 independently; switching transports after batching has mixed benefits.

• Batching: 2.59–4.82× faster on UDS and 1.83–2.43× on sync SHM for 30+ fields. Benefits persist on async SHM and Wasm too.
• UDS → sync SHM: 1.81–1.90× faster before batching. After batching: 1.80× at 3 fields, 1.34× at 30, and 1.09× for 50-field chunks; other scenarios are 1–6% slower. This run does not support a blanket switch for sponge performance.
• Small inputs: batching regresses three-field medians by <1% on every backend; overlapping quartiles make these differences inconclusive. One machine/run; small transport differences require caution too.
• Follow-up: Keep UDS for large, batched sponge absorption; investigate sync SHM for workloads with many small hashes.

Results

Median milliseconds per complete operation. Batching = old/new within a backend. New vs UDS = UDS new / SHM new; >1× means SHM is faster, <1× slower.

Native sync SHM (primary)

Fields	Chunk	Old ms	New ms	Batching	New vs UDS
3	3	0.0177	0.0178	1.00x	1.80x
30	30	0.162	0.0884	1.83x	1.34x
300	300	1.6	0.7	2.29x	0.99x
3,000	3,000	15.9	6.58	2.42x	0.96x
24,576	24,576	130	53.7	2.43x	0.98x
24,576	50	131	61.1	2.14x	1.09x
24,576	500	131	55.5	2.35x	0.95x

Native UDS

Fields	Chunk	Old ms	New ms	Batching
3	3	0.0321	0.0321	1.00x
30	30	0.307	0.119	2.59x
300	300	3.04	0.691	4.40x
3,000	3,000	30.3	6.29	4.82x
24,576	24,576	247	52.6	4.70x
24,576	50	247	66.5	3.71x
24,576	500	246	52.5	4.69x

Native async SHM

Fields	Chunk	Old ms	New ms	Batching	New vs UDS
3	3	0.0242	0.0244	0.99x	1.32x
30	30	0.224	0.113	1.99x	1.05x
300	300	2.23	0.693	3.22x	1.00x
3,000	3,000	22.2	6.35	3.49x	0.99x
24,576	24,576	181	53.4	3.40x	0.98x
24,576	50	180	70.9	2.54x	0.94x
24,576	500	181	53.4	3.39x	0.98x

In-process sync Wasm

Fields	Chunk	Old ms	New ms	Batching
3	3	0.0247	0.0249	0.99x
30	30	0.225	0.149	1.51x
300	300	2.24	1.28	1.75x
3,000	3,000	22.3	12.5	1.78x
24,576	24,576	183	103	1.78x
24,576	50	183	108	1.70x
24,576	500	183	103	1.78x

Measurement method

• Four explicit real backends, one thread, run serially on Apple M4 Pro; Node v24.15.0, bb.js/native 6.0.0-nightly.20260916.
• Time fresh sponge creation, absorption, serialization and squeeze. Exclude backend startup, input generation and validation.
• Three warmups; 15 paired samples alternating old/new. Pilot targets ≥100 ms/sample, capped at 1,000 repetitions (194/840 samples were shorter). No filtering or performance threshold.

Raw samples, quartiles and environment · Full methodology

Reproduce

From yarn-project, after installing dependencies and building:

SPONGE_BENCH=1 JEST_MAX_WORKERS=1 yarn workspace @aztec-labs/blob-lib test src/sponge_blob.bench.test.ts

Validation: all four backends agree on chunk states and final hashes across 20 cases. Existing tests passed before/after; full workspace build, formatting and lint passed.

[greptile-apps]

Confidence Score: 4/5

The benchmark appears behaviorally sound, but the two explicit repository style requirements should be satisfied before merging.

Findings

1.  Current PR Reference ▶
2.  Misordered Jest Import ▶

Summary

Adds an opt-in Jest benchmark comparing legacy per-field sponge absorption with batched absorption across four bb.js transports.

• Validates state and hash equivalence across 20 chunking cases.
• Records 15-sample median and interquartile measurements from an Apple M4 Pro.
• Adds the bb.js development dependency and documents methodology and reproduction steps.
• Remains skipped during ordinary test execution unless SPONGE_BENCH=1 is set.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Enable SPONGE_BENCH] --> B[Build deterministic scenarios and validation cases]
  B --> C[Select next backend in serial order]
  C --> D[Create explicit bb.js backend]
  D -->|Initialization succeeds| E[Compare old and new states and hashes]
  D -->|Initialization fails| F[Record backend failure]
  E --> G[Warm up each scenario]
  G --> H[Pilot old and new algorithms]
  H --> I[Run 15 alternating sample pairs]
  I --> J[Compute medians, quartiles, and speedups]
  J --> K{More backends?}
  F --> K
  K -->|Yes| C
  K -->|No| L[Write JSON and Markdown reports]
  L --> M[Fail test if initialization failures were recorded]

Loading

_{Reviews (1) · Last reviewed commit: "docs: keep sponge benchmark table in PR ..."}