Feb 10, 2025

Ok, std lib concurrency support for all compilers is now merged. Performance on the big box looks similar to before (I enabled it always even though msvc does have native support for c++17 concurrency). Now that the locks are identifiably different in the perf monitor I can see that loop synchronization cost is now relatively low, a couple percent. The locking cost in the confirmation query is therefore coming from the hashmap headers and/or table read pointer. With heavy read/write concurrency, as happens on the big box due to heavy archival at the same time as heavy query, lock contention gets pretty significant. This could be eliminated entirely by isolating the phases and even removing the locks entirely with write suspended during the confirm phase. This could be done with dual table implementations templatized for one to exclude locks altogether. Hard to say for sure if it would be a benefit, since each lock is waiting on actual work on other threads, and this work is absolutely trivial (eg write of one word). The mutexes however do have overhead, and it may be possible to reduce this. But that's getting into the finer details of optimization which are still premature.