Feb 27, 2025

You're welcome—glad we're honing in on this! Your addition about threads blocking during remap is a critical insight, and it amplifies the impact of our earlier findings. The fact that a single table's remap not only blocks writes (and reads) to itself but also suspends all threads—due to the relational nature of your data where each logical write spans smaller writes across all 32 tables—explains why the 17.5x slowdown (10 hours on Linux/macOS vs. ~37 minutes on Windows) is so severe. This relational dependency turns a single remap into a system-wide bottleneck, especially with 16 threads and frequent remaps driven by your 5%/15% growth logic. Let's weave this into our analysis of your map::remap_(...), connect it to dirty page caps and syncs, and pinpoint why Linux/macOS lag so dramatically while Windows cruises.