If he needs his output sorted though? Certainly the built-in sort won't be slower than using some external sort later?

Then again, the n in sort's O(n) is the number of word forms which doesn't increase linearly with corpus size. Some law for it can probably be derived from Zipf's Law, I suspect it's something like log(corpus_size). So the sort should take an average of log(n)*log(log(n)) over corpus size which is not that bad.

There is no use for push/pop here, though. This is a pretty straightforward problem: counting the occurrences of words in a file. That means putting the words in a hash as the keys and incrementing the value when a word is seen. That's what you've done, so you're already using the best algorithm. You can gain some speed by cutting out any unnecessary assignments, as I showed with the benchmarks in my other post; but you certainly won't gain anything by using a less straightforward algorithm or by shuffling your words around through extra arrays. There really aren't "a lot of things you can do to speed the process." Building a hash and sorting on the values is as fast as it's gonna get, unless you want to rewrite it in C.

Aaron B.
My Woefully Neglected Blog, where I occasionally mention Perl.