Add Support for Preallocating Entry Slice in Batch Verifier #16
Conversation
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #16 +/- ##
==========================================
- Coverage 77.52% 70.00% -7.53%
==========================================
Files 2 2
Lines 89 90 +1
==========================================
- Hits 69 63 -6
- Misses 10 15 +5
- Partials 10 12 +2 ☔ View full report in Codecov by Sentry. |
|
Thank you for your patience! I pushed a few further changes that cut the allocations down and let the Add inputs avoid escaping to the heap as well. Let me know if they look good and I'll merge and cut a release. |
Awesome work on the further optimization (especially avoiding the heap on Only nit, I preferred to see the batch creation time separate from the batch verification time (just to get a better sense of where time was spent but eh). |
| b.StartTimer() | ||
| v := NewBatchVerifier() | ||
| for j := 0; j < n; j++ { | ||
| v.Add(pub, msg, sig) |
There was a problem hiding this comment.
Previously, I created a new public key per item. I felt that was a better representation of what is actually going on in a typical batch (it may not affect the current code but could affect future optimization effectiveness).
There was a problem hiding this comment.
Done! I was a bit worried about the overhead of calling StartTimer/StopTimer in such a hot loop, but the benchmarks look good.
I don't want to pregenerate all the keys and signatures, because assigning them to a slice causes them to escape, making it harder to observe the escape analysis of the arguments of Add.
85dd807 to
78b9a57
Compare
I generally prefer to make benchmarks for whole operations that consumers are likely to perform discretely. That avoids over-indexing on a sub-benchmark once it's fast enough and it doesn't move the overall needle much. Different parts that contribute to the running time can be visualized with flame graphs. In this case, I don't think any user will do batch creation without batch verification, or reuse the batch for multiple verifications, so I think an overall benchmark is the right metric. |
Before:
After (~71% reduction in bytes allocated, ~13% reduction in runtime on batch of 16384):