The downside of radix trees is the space of algorithm designs is pretty exotic, especially high-performance implementations. It is much easier to write a good hash table implementation than a good radix tree implementation.
In the worst case, the cache behaviour of a radix tree could be awful, if each node lives in a different cache-line, no?
I imagine this problem can be ameliorated with a custom allocator, though.
Been a while since I've studied hash-maps in depth, but with a good hash function, that wouldn't be a big worry, would it?
In some scenarios, radix trees can overcome that with better space efficiency (i.e. implicit key storage), but I think it's fair to say that there are many scenarios (if not most!) where hash tables outperform radix trees.
Of course, that all hinges on how you measure performance. As Salvatore pointed out, if you're looking to minimize variance, hash tables might not be suitable due to their growth characteristics. Radix trees also give you efficient sorting and range scans out of the box, and are a viable immutable persistent data structure as well. If none of those are meaningful to your use cases, then hash tables could certainly be a better fit.
How could we support deletion of nodes?
Conventionally, a free list would be used, though admittedly that sacrifices locality which was one of the original motivating factors. To the extent that deletion is a significant component of the workload, then yeah, this doesn't help.
Radix trees never rotate, right? Can that be leveraged to help with locality?
{ i * "a" : i = 1 to n }
(also great for breaking string sorts)