Re: large perl module

There is no way of knowing other than by trying. A modern computer has easily at least 1 Gbyte of RAM so your data-structure which is a little over 1% of the RAM, shouldn't matter much, unless of course it takes away the very last free bytes and your OS starts swapping things in and out of the harddisk. At that moment you wish you had put al that data into a real database.

Indeed a hash is the fastest way of looking up that data, but do you really need split millisecond speed?

Also, keeping the data in the module itself is wasteful of memory: once the module has finished loading and compiling, you now have the whole of the module in memory PLUS the data in some variables. If you go for the data to be loaded from a data-file (say a YAML or JSON file) then you can save at least the amount of data you now store in your module.

Update:I now note that your module runs in a "mod_perl" environment. You have to be very careful in designing your programs so that you avoid the big module being private to each child process, since these child processes are regularly reaped and respawned by the web-server (see the Apache MaxRequestsPerChild Directive) and thus will reload your big module again and again and again. Ideally your data-structure should remain shared over the server's lifetime. I guess that on a heavily loaded system having to regularly reload your data will cost you more time and resources than looking-up the data in a database does.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Comment on Re: large perl module

Replies are listed 'Best First'.
Re^2: large perl module by almut (Canon) on Mar 04, 2010 at 22:18 UTC
... and thus will reload your big module again and again I think the effects of this largely depend on how things are configured. Let's say `MaxRequestsPerChild` is set to 10000 and an average request takes 500 ms^() to be delivered, then the total time of service of one process will be >= 5000 secs. Assuming the reload time of the module is in the order of 5 secs, this will still be a ratio of only 1 : 1000 (in other words, acceptable). ___ ^() I hadn't yet seen the OP's reply above when guessing that number (which would be more typical when serving end users over the web).	[reply] [d/l]
Re^3: large perl module by minek (Novice) on Mar 04, 2010 at 22:27 UTC
Within Apache it might be of course different, but judging from running a test perl script from command line, the load time of the script/module is below 0.5s And the MaxRequestsPerChild is actually set to 10000. So it should be fine.. Thanks, Dan	[reply]
Re^4: large perl module by CountZero (Bishop) on Mar 05, 2010 at 07:05 UTC
And then your webserver has to service 1000 requests per second and it goes down every 10 seconds. It is not just the loading of the module that needs to be taken into account, but also the time spent in cleanly destroying the child workers and restarting them. That can actually take a lot longer and thus you want to keep the total time as short as possible, by avoiding long loading times of modules. Every second saved helps. It is just a gut feeling, but a database solution feels more efficient to me. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]
Re^2: large perl module by minek (Novice) on Mar 04, 2010 at 22:08 UTC
Any hints on doing this (shared 'module')? Right now mod_perl script looks like this: `use GiantModule(); use CGI; .... my $carrier = GiantModule::lookup($phone_number); .... exit 0; ###################### That's how the .pm looks like: module GiantModule; my %carrier = ( .... GIANT HASH .... ); sub lookup { my $phone=shift; ..... return $carrier{.....}; }` [download]	[reply] [d/l]
Re^3: large perl module by almut (Canon) on Mar 04, 2010 at 22:32 UTC
See Sharing Memory, and in particular Preloading Perl Modules at Server Startup in the mod_perl docs (even though this is the 1.0 docs, most of the discussion still applies).	[reply]
Re^4: large perl module by CountZero (Bishop) on Mar 05, 2010 at 06:53 UTC
most of the discussion still applies But only in a very general sense. Better look at the version 2.2 docs and more specifically the comments on the Postconfig Handler. But even if you load the module that early in the server startup-cycle, there is no guarantee that the data will stay shared for the lifetime of the server. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]
Re^5: large perl module by almut (Canon) on Mar 05, 2010 at 07:03 UTC