Apr 10, 2025

I was just finishing up the compact filters integration (bip157/158) with some performance runs, and to measure the variable table size. I flipped on the performance profiler and was shocked to see that like 95% of the entire milestone run was being consumed by siphash and chain::script::to_data(bool) (both within golomb_coding). These were both the result of using the boost-based iostream with the associated reader and writer. I removed this from performance critical network and database operations about a year ago, but until now I haven't seen quite so clearly how expensive it was. After swapping in the fast iostream and read/writer, these aspects barely register (less than 2% of the run). Crazy.