## Benchmark results

| Benchmark | Native Performance | Snap Performance | Performance Penalty* |
|----------------------|-------------------:|--------------:|---------------------:|
| "xor" prover | 43.(6)ms | 136.(3)ms | 3.12x |
| "withdraw" prover | 7.163s | 25.616s | 3.58x |
| "jf_withdraw" prover | 34.401s | 119.251(3)s | 3.47x |
| "xor" key generation | 107ms | 374.(6)ms | 3.5x |
| "withdraw" key generation | 8.203(6)s | 26.266s | 3.20x |
| "circuit generation" key generation | 639.(6)ms | 581.(6)ms | 0.91x |
| "srs generation" key generation | 4.564s | 6.907s | 1.51x |
| "keys generation" key generation | 38.037(6)s | 107.828(3)s | 2.83x |

*(1x is Native)

## Updated Analysis

The performance penalty has stabilized at around ~3.25x for most operations. This is consistent with previous benchmarks of WASM workloads in snaps. The likely source of the overhead is the freezing of `TypedArray` in [SES](https://github.com/LavaMoat/LavaMoat), a sandboxing technique used to prevent malicious code from affecting the MetaMask runtime.

Possible solutions to this issue have been discussed with the LavaMoat developers. However, any substantial changes would probably require initiating a dialogue with the V8 JS engine developers, which could be a time-consuming process.

## Next Steps

In order to report this issue upstream, I plan to isolate and reproduce the performance problem. Additional updates will be provided as progress is made.