perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2] perl_clone takes 5 and more seconds to complete
Date Wed, 05 Nov 2003 09:02:40 GMT
Elizabeth Mattijsen wrote:
> At 11:40 -0800 11/4/03, Stas Bekman wrote:
> 
>> The only bright side I can see at the moment is that most people won't 
>> have 150 modules loaded. But 50 modules will scale bad enough.
> 
> 
> Agree.  Which is why I think you really will have to know what you're 
> doing if you want to use mod_perl with a worker mpm.

But it's not an option on win32 platforms :( We just hoped that mp2 for the 
first time will make win32 as a viable platform for modperl...

> This may be old news to some, but I wrote an article about this about 
> two months ago on Perlmonks: Things you need to know before programming 
> Perl ithreads.
> 
>    http://www.perlmonks.org/index.pl?node_id=288022

Yup, you kindly pointed me to it when you wrote it. It's a very good article.

> So, in the worker mpm, you need to load as little as possible before 
> cloning, and only load modules when they are really needed inside the 
> thread.  This is perpendicular to prefork mpm, where you want to load as 
> much as possible beforehand.

The problem is with 3rd party modules, which may load things they may never 
use, by calling 'use module' on the top, instead of calling 'require module' 
where it's really needed. So you end up with dozens of modules loaded that you 
don't really use. Too bad we can't unload modules.

> One of my related projects is load.pm (on CPAN) which is an AutoLoader 
> type module with a twist.  It allows for a more flexible way of loading 
> modules.  It allows external control over whether a module will load 
> subroutines on demand or all subroutines at once. In a worker mpm you 
> would want on demand loading, for a prefork mpm you'd want it all at once.

You have at least one problem to deal with, subs that get "autovivified" from 
air at 'require module' time. e.g. look at Apache::TestTrace -- it creates a 
whole bunch of subs on the fly.

> As my plan for world domination, all core modules should use "load.pm", 
> or the load.pm functionality should somehow become part of interpreter.  
> I'd appreciate feedback whether this is a good idea, or just a delusion 
> of grandeur on my part.  ;-)

You give us too little details to give you a constructive feedback, Liz.

What I'd like to see is this. overload require and register all the used 
modules (I think James Smith wrote such a module, Module::Info?) then get the 
stats on which modules are really used by running coverage testing (hopefully 
covering all possible paths, including erroneous ones). Next instruct 
require() to ignore any requests to load modules which weren't used so far, 
returning success to the caller. The implementation seems to be easy, the hard 
part would be to come with coverage tests, and most people will fail to do 
that, which renders my idea not so practical...

I don't know if trying to go into the guts and prune the unused OpCode tree 
chunks will help. e.g. add a new new flag to each CODE opcode telling whether 
it was used or not. then if it wasn't purge it or don't clone it... I guess 
that's what COW will do more or less...

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message