Lowercase alphabetic strings happen to not induce any hash collisions with the current choice of hash function. Sprinkling in digits so that characters are chosen from ['0'..'9']++['a'..'z'] sends the collision rate through the roof, to something like 80%. Really, any choice of >33 characters seems to work reasonably well; you can for example try mixed upper and lower case. Using more interesting string data would permit realistic benchmarking (and would encourage the use of a less problematic hash function, I bet).
We should switch to MurmurHash sooner rather than later. The reason I haven't done so yet is that
Most likely the benchmarks were flawed. I ran two kind of benchmarks: one benchmark measured hashing throughput in MB/s and the other was the unordered-containers benchmark.
Perhaps an alternate strategy is in order:
It might be worth changing the test data as described, and then repeating the benchmark. As I noted, you happened to have chosen a small enough range of characters that collisions don't really happen. Crank the range up a tiny bit, and I expect MurmurHash will suddenly look much better. :-)
Note that Mumurhash has a final mix step that can be skipped in the particular case of HashMap. This step just moves data around the hash so that (eg) using the low-order or high-order bits will yield low collision rates. The final mix can only increase collisions if you're using all the bits of the hash. HashMap is weird in this respect.