The .NET Dictionary class includes a protection mechanism against hash flooding attacks. When the number of collisions in a single bucket exceeds 100, the dictionary switches from a non-randomized string comparer to a randomized one. This transition occurs upon the 102nd insertion, forcing a recalculation of hash codes and redistributing entries across multiple buckets.
This defensive mechanism is only active when using default comparers like Ordinal or OrdinalIgnoreCase. Custom comparers bypass this protection, which can lead to performance degradation if keys are specifically crafted to cause collisions. In such cases, search operations revert from O(1) to O(n) complexity, as the processor must iterate through a single bucket chain.
For 64-bit architectures, the dictionary optimizes bucket index calculation using a technique described by Daniel Lemire. Instead of using the expensive integer division operator, it employs a precomputed multiplier to perform division via multiplication and bit shifting. This method is significantly faster than the standard modulo operator used in 32-bit builds.
The constant 101, often found alongside the collision threshold, serves a different purpose related to table sizing. It originates from the legacy Hashtable implementation to avoid specific prime number sizes that could cause issues with double hashing. While modern Dictionary implementations do not use double hashing, this constraint persists in the shared HashHelpers utility.
