http://www.perlmonks.org?node_id=464431


in reply to Re: More than mod_cgi less than mod_perl.
in thread More than mod_cgi less than mod_perl.

OK. My bad. I tougth that it's clear that I'm trying to improve only Perl's performance. Of course if other languages benefit - it's even better.

And how about adding functionality to perl, so that it cleans up memory before next run, on itself. Correct me if I'm wrong, but such function must be in perl allready and is curently called before it exits. Altho would probably need minor modifications. Not counting
  • Comment on Re^2: More than mod_cgi less than mod_perl.

Replies are listed 'Best First'.
Re^3: More than mod_cgi less than mod_perl.
by Gilimanjaro (Hermit) on Jun 07, 2005 at 22:00 UTC

    The memory cleanup on perl's exit, is a whole other type of cleanup I'm afraid. Perl allocates a bunch of memory from the OS, but the problem is in how it uses this memory itself. The memory is returned to the OS at perl exit offcourse.

    Doing the same kind of cleanup without exiting perl would probably not be a trivial change to perl. Just an example of a problem you'd encounter would be how to handle the special global variables that are linked to the perl parameters from the shebang (#!) line...

    A bigger problem though, would be that cleaning up all of the memory would mean all modules would have to be reloaded too, and the module loading and initialisation is often even slower then the perl interpreter loading...

    As a perl module can change variables in *any* namespace, so we can't just clear the part of the namespace it's using, and keep it loaded. There is just no proper way to 'reset' a running perl to initial state. The 'flow' of compilation can change, because of the existence of stuff like BEGIN blocks, so the line between compilation time and runtime can get blurry. This makes resetting perls internal state even harder...

    It's for these reasons that mod_perl has the complexity is has, and that the programmer needs to be aware of the persistent behaviour some variables may exhibit. There's just no way around it I'm afraid... Not without removing a ton of functionality from perl itself, which in turn would break half the modules out there that people are using.

    It's a hard subject to explain without getting into deep technical detail, but I hope I've hinted in the right direction...

      I know that perl's exit cleanup is another type of clean up. And of course built in/special variables would need to been take care of. I still belive that it wouldn't be that difficult to do this. Altho BEGIN/END blocks do raise some questions ...

      Still, I believe that doing everything that is usually done on each CGI request, except reloading perl itself will give a boost.
      Question is will that be enough faster to bother with it?

      Anyway, if FastCGI is the solution then why aren't all hosting's using it (instead of using mod_cgi and whatever other web servers have for CGI)?