Speed considerations of ffi #886
Description
I noticed that BDK ffi is slow. E.g. the peek_address takes 0.2ms which quickly adds up to the range of seconds.
Similar with crucial functions like __str__ .
I assume the actual bdk code is fast, which leaves the ffi interface. The apparent overhead seem to be the ffi wrappers:
I am not sure how to circumvent this. One idea is that one could try to batch operations. Instead of peek_address 3000 times, one could give a range or list of indices and get a batch back. It is however not certain that this would help. It probably depends on how often these ffi wrapping functions are called.
batching test
Using https://github.com/andreasgriffin/bdk-ffi/tree/add_peek_address_batched which adds peek_address_batched with
benchmark.py the results are
Sequential peek_address duration: 0.131605s
Batched peek_address_batched duration: 0.100451s
which hints, that simple batching is not sufficient for a speed improvement.
links
https://mozilla.github.io/uniffi-rs/latest/internals/lifting_and_lowering.html
tagging: @thunderbiscuit