Difference between a declared hash and stored one with storable.

mohan2monks has asked for the wisdom of the Perl Monks concerning the following question:

HI
I have a script that generates report, the scripts gets data represented as codes, the definitions for these are static.
e.g. data has city codes like NYC and i have a hash which look like

my $bighash={
NYC =>{CITYNAME=>'NEW YORK',STATE =>'', PROVINCE=>'' ...},
...
...
...

};
[download]

As this hash is static i have defined it like above and saved to a file to disc as cityhash.pl
I have other such data hashes which i have declared and saved to files on disc.
I require those in my code when that data is to be decoded like

require "cityhash.pl"
$bighash->{$citycode}->{CITYNAME} #access name and other information l
+ike this
[download]

What is the difference in this approach and using a storable module to store this hash once and then use that as required.
Is there any benefit to memory consumption with storable as it stores data in binary format.
Please suggest if there is another approach to this. This currently is a CGI script and will also be trying make it work under mod_perl.
Pointers in that direction are welcome.

Comment on Difference between a declared hash and stored one with storable. Select or Download Code

Replies are listed 'Best First'.
Re: Difference between a declared hash and stored one with storable. by McA (Priest) on Feb 06, 2014 at 08:13 UTC
Hi, just my opinion: When you use require and you use this hash everywhere than you could also make a module (*.pm) with a module global hash and simply `use` this module. This would transfer the instantiation time of the big hash to the compile time. A hash in perl notation is simpler to edit than a hash represented as a Storable object. I would think much more about another thing. When you use the global hash the using party has to know the keys and the structure of that hash. Therefore the knowledge about the hash is spread all over the code which uses it. That makes it hard to change somthing in teh hash when you have to. I would encapsulate the whole hash into a object holding the informations and querying this object with methods which fit the common use cases. This gives you an abstraction from the way you implemented it. Then you can store it as a package global hash, as a hash which you slurp at runtime via require or you slurp a storable representation of that hash or you put the whole thing into a database. You can even change the structure as long as the querying methods don't change their API. Best regards McA	[reply] [d/l]
Re: Difference between a declared hash and stored one with storable. by Discipulus (Canon) on Feb 06, 2014 at 08:40 UTC
Can I suggest you to use a database? maybe i have not understood the question but store similar data brings me to BD. I'm not an expert but develop the web part with Dancer or a similar Perl web framework, and use Plack instead of plain CGI. hth L* There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.	[reply] [d/l]
Re: Difference between a declared hash and stored one with storable. by Anonymous Monk on Feb 06, 2014 at 08:20 UTC
I require those in my code when that data is to be decoded like require won't create any my vars in your program, see Including files details Is there any benefit to memory consumption with storable as it stores data in binary format. No, the same hash will use the same amount of memory (RAM) Storable might take slightly less disk space, but it would still take the same amount of RAM	[reply]
Re: Difference between a declared hash and stored one with storable. by locked_user sundialsvc4 (Abbot) on Feb 07, 2014 at 01:25 UTC
After trying various things in various projects, here’s what has consistently worked best for me: an SQLite database file, containing data stored in YAML format, all of which data is read-only. (Modification is not allowed, because it would be impossible to keep all of the various persistent CGI-servers in sync.) If you know that strings are likely to be used over and over again, especially in a persistent environment like mod_perl (or FastCGI), you might decide to maintain a small Cache (there are many flavors available, ready-made ...). But the principle is the same: most of the data is kept on disk, and demand-loaded, with a reasonable and adjustable cap on the number of entries that are allowed to be in memory at once. I specified YAML because I have had “unexpected problems” that I could never quite explain with Storable. (I’d store stuff and then be unable to get it back.) So, I use this format, which also has the big advantage of being human-readable. Note also that I am rarely dealing with “every microsecond counts” performance-laden situations, so Your Mileage May Vary.™