The slower random-hit case belongs next to the improved miss case, exactly as you show it. One extra workload I would keep in the regression set is a fixed live-key count with repeated delete/insert cycles. That separates table size from tombstone history. Run the same present and absent lookup keys before and after the churn, and retain both probe counts and elapsed time. Otherwise a freshly built table can pass while the long-lived version takes a different path. This would also give the shared lookup/insertion/deletion probe sequence a useful correctness check: surviving keys must remain reachable throughout the cycle.