Depending on how many millions of unique values you might be dealing with in any particular run, a completely different approach
might also be called for...
Your present algorithm is based on the assumption that "hashes are 'free.'" Unfortunately, when a hash grows into hundreds-of-thousands or millions of entries, it is no longer free. Instead, every single access runs the risk of a page fault.
The application, and the system itself, slows to a crawl...
An "unexpectedly different" algorithm would write all those keys to a disk-file, then sort
that file (on disk...), and count them. When a file is sorted, all of the occurences of any particular key-value are guaranteed to be adjacent. "Counting" them, therefore, requires no main-memory at all.
Yes... this is
"how they did it with punched cards, even before digital computers existed."
... it still works.
(In fact, it can out-perform algorithms such as yours by a factor of thousands . . . )