This reminds me of a situation that I encountered a few years ago while doing some work for an online bookstore.   They wanted to extract a sorted list of book-IDs and do something with them.   But the “tied hash” was actually a Berkeley DB.   (They loved Berkeley DB’s, for some reason.)   Trouble was, there were literally millions of records in that file.   Logic which began with sort keys promptly fell-over and died, because the computer was attempting to build an in-memory list of all those records.

I pointed out that, in the specific case of a file of this kind, the each() function will reliably return the keys in sorted order, because it is simply walking through the B-tree structure.   Thus, the entire approach of “fetching all the keys, sorting them in memory, and querying for records using these keys” could be eliminated in favor of a while loop.   The memory-load evaporated and hours of processing time were saved.

Of course, this only works for the (one) key under which the records are stored, in such a file.   And, generally speaking, it only works because the “hash” in this particular case was not, in fact, a true hash at all.   The each() function does not exhibit this behavior generally.   This was a special case, and an uncommonly-useful optimization that could be brought to bear in that special case.

(Today, given a similar situation, I would recommend using SQLite database files, although that technology did not exist at that time.)