in reply to Re^3: when is "my" not necessary?
in thread when is "my" not necessary?

Folks, as lovely and complete as your responses were, they were merely explanations for the differences between %hash{} and $hash->{}. My question, however, was what is the advantage of using one over the other? Obviously, there are contextual sitautions where you are supposed to use one instead of the other, but in cases where you are just creating a dynamically growing hash, does it matter which?

If the question is still too simple to answer one way or another, how about answering this: under what conditions is one more efficient memory-wise, performance-wise, or otherwise?


Independently of that question, let me throw in this: I have a text file that I parse with perl and build hashes based on that data. Think of it as a cross-referencing dataset with references pointing every which way. In order to avoid reparsing this each and every time the program starts up (it'll be a cgi script, and the data it reads is static), what would be the best way to just dump the hashes into a file and load it back up in one swell foop so as to optimize performance? Would the above "Dumper" package be a good choice? And in this case, would I want to use the hash reference form discussed above?

dan

Replies are listed 'Best First'.
Re^5: when is "my" not necessary?
by runrig (Abbot) on Nov 17, 2004 at 00:37 UTC
    what is the advantage of using one over the other?

    The syntax when dealing with hashes is simpler than when dealing with hash references. When I want to pass them around as arguments though, I tend to use hash references instead. And if you want a hash to be part of a larger data structure, you have no choice but to use references (unless you use a glob, but let's not go there).

    what would be the best way to just dump the hashes into a file and load it back up in one swell foop so as to optimize performance? Would the above "Dumper" package be a good choice? And in this case, would I want to use the hash reference form discussed above?

    Data::Dumper is good for "seeing" the contents of a data structure for debugging purposes, but for storing and retrieving data, Storable deals better with things like odd characters such as line feeds in the data, though the file it creates is not readable like the output of Data::Dumper. You can also look at things like DBM::Deep (update: or YAML or XML (e.g. XML::Simple) modules).

      I hope I'm not out of line in adding Data::Dump::Streamer to the list. It not as fast as storable or Data::Dumper but its a lot easier to read and handles a lot of the weirder cases better and more accurately than DD.

      ---
      demerphq