Benchmark generation of public randomness proof #68
Labels
Comments
Lazar955
added a commit
that referenced
this issue
Dec 4, 2024
For numPubRand ≤ 1000, the growth appears roughly linear, with execution time increasing by similar factors as numPubRand --- Benchmark ran on M3 Pro. numPubRand | Iterations (b.N) | Time per Iteration (ns/op) | Approx. Time (ms) | Approx. Time (s) -- | -- | -- | -- | -- 10 | 38 | 29,210,366 | ~29.2 ms | ~0.03 s 50 | 16 | 68,297,312 | ~68.3 ms | ~0.07 s 100 | 9 | 120,456,028 | ~120.5 ms | ~0.12 s 200 | 5 | 224,715,767 | ~224.7 ms | ~0.22 s 500 | 2 | 536,105,584 | ~536.1 ms | ~0.54 s 1,000 | 1 | 1,056,664,416 | ~1.1 s | ~1.1 s 5,000 | 1 | 5,159,288,750 | ~5.2 s | ~5.2 s 10,000 | 1 | 10,353,431,958 | ~10.4 s | ~10.4 s 25,000 | 1 | 26,828,946,167 | ~26.8 s | ~26.8 s 50,000 | 1 | 53,123,792,875 | ~53.1 s | ~53.1 s 75,000 | 1 | 156,188,836,166 | ~156.2 s | ~2.6 m 100,000 | 1 | 211,468,613,458 | ~211.5 s | ~3.5 m ---  --- References [issue](#68)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For each commit of randomness, the fp needs to generate corresponding merkle proof of each randomness number and save them into db. This introduces overhead, so we should do benchmarking to explore a recommended number of randomness for each commit set in the config,
NumPubRandandNumPubRandMaxThe text was updated successfully, but these errors were encountered: