Re^3: 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?

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]