While i agree that this solution works, it only works in the very isolated situation where you are reading the keys from a file and that you get $. effectively for free (not really, but Perl is going to manipulate $. anyway)

But in general this solution does not work directly. If the hash is being populated in a different way than by reading the keys from a file then $. is lost.

Sure you could pick some other variable to be the order count for the keys, something like:

my %h;
my $h_order = 0;
while ( my $key = get_key_from_somewhere() ) {
   if ( ! exists $h{$_} ) {
      $h{$_} = $h_order++;
   }
}
[download]

But then $h_order will need to be passed around with %h if any other values are going to be assigned, not to mention always performing the additional logic whenever assignments occur. If %h is going to be used in some function that i don't have control of the internals then the order is lost.

I still stand by my Tie::IxHash solution because with it, other code that uses %h doesn't need to know anything special about it, it just operates like it was set up to operate.

As for the overhead of tieing, it is rather small. Perhaps a 5-10% decrease in performance over using an untied hash, but the untied hash doesn't give the needed usage, so in implementing the functionality you need, you are losing the performance gain from not using the module.