If you really can't use mod_perl, then you could try to defer the module loading. Normally this is done by removing the "use" statements and put "require" statements at the point where the functionality is needed. Of course this is error prone and you have to fully qualify function calls.
Maybe it's worth to take a look at the autouse module, which automates the deferred load of modules.
| [reply] |
I know that you can use storable to store and load stuff directly to memory (much faster than Data::Dumper). Could this process be used to store the 'loaded' version of all the modules?
Over the last decade there have been several implementations along those lines, at first involving dumping a memory snapshot for the process, and then more recently using stored bytecode with the B modules.
However, for production web work, I think mod_perl's a better answer. | [reply] |
mod_perl is only a better answer if its an option. Yes I know move to a different host if your doesn't have mod_perl, but then thats not realy an answer is it? Perhaps it could be considered one. The real question is why do we have to wait for perl to compile a module, i mean its going to be compiled the same everytime isn't it? At least on the same system, so why not save it right after that compiling process? Its possible, maybe even likely, that this is impossible or just very difficult, or just impractical. Could someone with more intimate knowledge of perl, than myself, explain why this would be bad or impossible?
Thanks.
| [reply] |
The real question is why do we have to wait for perl to compile a module, i mean its going to be compiled the same everytime isn't it?
When a module is loaded, it isn't just "compiled" -- it undergoes a multi-part process including parsing and execution that produce run-time changes in the state of the Perl interpreter. A module can load other modules, install symbols in other packages, and perform other "compile-time" actions that are difficult to freeze in a static form.
As a result, most of the dump/compile techniques are intended to work with entire programs, not individual modules. (See the perlcompile manpage and the B::CC module.)
I think you might be able to process individual modules using B::Bytecode and ByteLoader. This might improve performance by a bit, but I believe the overhead and limitations will prove daunting.
| [reply] |
mod_perl is only a better answer if its an option. Yes I know move to a different host if your doesn't have mod_perl, but then thats not realy an answer is it? ...
mod_perl is always an option. Bytecode is never an option. perldoc B::Bytecode ...
BUGS
Output is still huge and there are still occasional crashes during
either compilation or ByteLoading. Current status: experimental..
| [reply] |
Thanks Eric. That's what I meant to ask actually! I have experience with mod_perl, but am having problems getting it to work at the moment (on AIX) and have a bad feeling I might have to rebuild the perl! | [reply] |