Re^2: Do multiple use statements across module dependency hierarchies require as little expense as multiple require statements?

Ah! Very wonderful of you to point out the mod_perl gotcha! Indeed, require would be a catastrophe under this environment? The calls would be unavailable or the whole thing would have to be recompiled, etc?

Yes, as you speak. The modules are loaded on call, not by default. And that is why it runs fast, because what's not "used" is not sought.

This is not just useful in cgi by any stretch of the imagination.
This is also *incredibly* useful in command line apps that may be able to do various different things.
Or maybe your script has a %50 chance of failure for some reason, and should exit as soon as possible.
For example, things on cron, that maybe have to do an expensive task at any moment, and are checking every 60 seconds if this procedure should or not happen.
The require would not be reached unless conditions are met, thus, quick and cheap.

Really helps speed things up, with an interpreted language.

Comment on Re^2: Do multiple use statements across module dependency hierarchies require as little expense as multiple require statements?

Replies are listed 'Best First'.
Re^3: Do multiple use statements across module dependency hierarchies require as little expense as multiple require statements? by chromatic (Archbishop) on Jan 10, 2008 at 20:41 UTC
Ah! Very wonderful of you to point out the mod_perl gotcha! Indeed, require would be a catastrophe under this environment? The calls would be unavailable or the whole thing would have to be recompiled, etc? In a persistent and forking environment, the more likely-constant items you load into memory before forking, the more you can share between processes with copy-on-write memory. If most processes will use a module and you don't load it before you fork, each one will suffer the stat calls and loading time and importing time and use non-shared memory to load the code. If you do load before the fork, you only pay for the loading and compilation time once, and all subsequent processes will transparently use the same memory pages.	[reply]
Re^4: Do multiple use statements across module dependency hierarchies require as little expense as multiple require statements? (minor) by tye (Sage) on Jan 10, 2008 at 20:56 UTC
"catastrophe" is certainly over-stated. Since the extra disk interactions to load the module will still be fairly small and will only be done once over the hopefully thousands of requests that will be handled by one apached process, the impact of having to load a module in every apached child is likely not very significant. As for sharing memory, that can work to the extent that the things loaded into memory by the module land on pages that are never modified in the child processes. Given the nature of Perl, I suspect that only a minority of the extra memory allocated will stay shared for a significant length of time, perhaps only a tiny fraction of it. So the down-side to delayed loading under mod_perl is often going to be quite minor, I expect. So I'd lean toward delayed loading and use mod_perl start-up options to force pre-loading of widely-used larger pieces. - tye	[reply]