4 measured workloads · Node.js · Apple M4 Pro
Typical processing
3.92 µs
Busier blocks
4.08 µs
Share of the test budget
0.3%
32-tap decaying IR · 96 kHz · 1.333 ms available per block in this test.
Processing time in µs · lower means less work
Timing varied between repeated tests. Treat this case as a guide.
Gain · dB
| Sample rate · kHz | Workload | Typical · µs | Busier blocks · µs | Test budget used | Observations |
|---|---|---|---|---|---|
| 48 | 22.29 | 27.25 | 1.0% | Timing varies | |
| 48 | 3.96 | 4.29 | 0.2% | Timing varies | |
| 96 | 22.79 | 28.46 | 2.1% | Timing varies | |
| 96 | 3.92 | 4.08 | 0.3% | Timing varies |
Times are per 128-frame audio block. Test budget used divides the p95 time by the block period at that case’s sample rate. Machine and runtime are shared.
Node.js · Apple M4 Pro · 48 / 96 kHz · 128 frames per block · 3 repeated tests ·
Typical summarizes the middle measured block times. Busier blocks summarizes the time that 95% of blocks completed within in each repeat. These figures measure DSP processing; application scheduling, loading samples and device output require separate checks. Memory and signal probes run separately from the timing loop.
Lean 4 checks algorithm properties and candidate optimization rewrites within stated assumptions. A model proof does not establish that an optimization is enabled in this node or on any target. Performance measurements establish speed.
6 Lean 4 results: 5 proofs in their stated domains; 1 counterexample.