The following table gives an overview of producing race warnings for ypbind_comb from bench:

This confirms that the MHP component for collected accesses can have a significant performance impact on race warnings. The reason is that for each access location it can create many more accesses based on the thread ID and especially the created threads set. So in large programs with many variables and accesses, this has the measurable impact from above.

Therefore it might be useful to be able to dynamically (de)activate what information is collected for accesses to trade off between precision and performance. If on these programs MHP doesn't really rule out races, then for interactive benchmarking it would be beneficial to disable it and save time.