carllin

We always used DashMaps: https://github.com/solana-labs/solana/pull/14212/files#diff-95c60d63a9644e0efe4da37f0ccd4d7169a459e0c963170888b1fd56f340b3c6R22-R24 💀 I didn't do nearly as much benchmarking as @dnut here, so I'm inclined to merge this. I'm looking through the benchmarks for curiosity, but...

@dnut, for clarification, these tests were done with this `expensive` flag enabled to replicate the secondary index scan right? https://github.com/dnut/dashmap-benchmark/blob/6465c044a67f3146a951d9b88ae681d285335f0c/src/lib.rs#L109-L110

After reading through the benchmarks (very detailed by the way, great work!), a few things: 1. My main concern is not slowing down writes to the secondary indexes, which comes...

yaasss fix my bugs king @brooksprumo

Adding some context for the order of events that causes this in PohRecorder. @steviez might be good to add this to the problem description: 1. `reset_poh_recorder` in ReplayStage is called,...

I think 1 is the right fix, we can cache the result of the check in `PohRecorder` so we can fail earlier in the `PohRecorder::reached_leader_slot()` . The cache could live...

@AshwinSekar it's a bug in PohRecorder. The block is made on a minor fork, gets pruned when a root is made, then gets recreated later b/c of the PohRecorder bug....

heh @ryoqun this is for optimizing replay to guarantee parallelism right? Yeah, for replay you can do this where you essentially schedule all the conflicting transactions into the same "span",...

Changing banking stage to do this might not be feasible due to fee priorities, see discussion here about how lower fee transactions might starve higher fee transactions: https://github.com/solana-labs/solana/issues/23211#issuecomment-1050296442 Essentially lower-fee...