Secp operations during txid computation
RCasatta opened this issue · comments
In a performance profile in a downstream project I noticed txid() is taking too much time even considering it's an expensive computation, in the flame graph there were calls to secp function which I don't think should happen?
Can share the performance graph if can help understand
Sure. What secp function was it?
I had to leave the PC... I remember fe_sqrt and others, will post tomorrow
Here are a convenient screenshot and the profiler json (to be loaded from chrome dev tools, performance tab)
For what I understand is how the PedersenCommitment is serialized with secp256k1_pedersen_commitment_serialize
Ok, yeah, the issue is in libsecp256k1-zkp, not here. For some bizarre reason secp256k1_pedersen_commitment_serialize decompresses the point then recompresses it, when all it needs to do is a memcmp (I think). So this function is wasting a lot of time for no reason.
Issue has been fixed in the upstream lib, I think we need
- secp256k1-zkp-sys upgrade to catch the changes
- rust-secp256k1-zkp release
- upgrade dep here (if rust-secp256k1-zkp not released as patch version)
Bumping secp-zkp requires bumping secp, which requires bumping bitcoin, which requires bumping bitcoind, which requires bumping elementsd.
I am almost done this. Opened RCasatta/elementsd#18
The next version of rust-bitcoin will break out the "types that never change" into a new primitives crate which should be sufficient for most of the other crates in the ecosystem, and which should rarely have major version bumps, which will make this all way less painful.
Fixed with #209
next release will take this