Feb 16, 2025

Actually the confirmation phase is now just a tiny percentage of what it was previously, as most of the work has been moved into the validation phase. That tiny percentage is small/fast enough that it gets subsumed by validation/download processing, so the CPU stays at 100% instead of everything waiting on slow confirmations. An entire table has been removed from the process, since that data was already readily available during validation. All of the costly confirmation querying has been moved to the parallel-by-block validation phase, which also means that there is no need for those queries to be in parallel std lib loops. This removes a lot of threading overhead, since we are already paying for concurrency by block. The prevout cache (passed from validation to confirmation phases) is 2x larger because I added the sequence value. This can be optimized by only storing the sequence after bip68 activates, and only storing it when the relative locktime bit is set. But even at full size it's not bad, and can be deleted at any snapshot/start/stop. I can't say that this will help the mini, since it will remain a question of disk paging, but I expect material improvement on the maxi. But there has been a significant paging reduction for sure. The remaining cost of the confirmation paging is really just reading point hashes to identify hashmap conflicts. That has also been reduced significantly by passing the "self" hash directly from the deserialized block into the confirmation query. I'm pretty sure that by splitting out the hashes form the point table this will be reduced even further.