I am not that far, yet. I am doing all my development work under Windows
and only for production I will use Linux (or Solaris if it needs bigger
iron).
Something to bear in mind then is that apache on Windows is (usually)
multi-threaded rather than multi-process. So a lot of the discussion in t
I won't try to speak for Michael, but technically that memory does not
become available for reuse by Perl, even if they are lexical variables
and they go out of scope, unless you explicitly undef the variables.
Perl keeps the memory for them allocated as a performance
optimization.
That was the
On Sat, Oct 25, 2008 at 7:34 AM, Clinton Gormley <[EMAIL PROTECTED]> wrote:
> Michael Peters' comment about memory reuse was saying that:
> - if at runtime, you load a large memory structure
> - then let those variables go out of scope
> - then that memory will be come available for reuse by Perl
On Sat, Oct 25, 2008 at 7:32 AM, André Warnier <[EMAIL PROTECTED]> wrote:
> And they do "remember" some things between consecutive runs of scripts
> or modules. That is usually undesirable, because it can give nasty
> errors : a variable that you declare with "my $var" and that you expect
> to be
On 25.10.2008 13:34 Clinton Gormley wrote:
> I think there was some confusion here about what was being said.
>
> Michael Peters' comment about memory reuse was saying that:
> - if at runtime, you load a large memory structure
> - then let those variables go out of scope
> - then that memory w
Michael Lackhoff wrote:
On 24.10.2008 15:03 Michael Peters wrote:
This is only true if those structures were created during run time and go out of scope at run time.
If they are generated at compile time or attached to global variables or package level variables,
they will not be re-used by Pe
On Sat, 2008-10-25 at 05:59 +0200, Michael Lackhoff wrote:
> On 24.10.2008 15:03 Michael Peters wrote:
>
> > This is only true if those structures were created during run time and go
> > out of scope at run time.
> > If they are generated at compile time or attached to global variables or
> > p
On 24.10.2008 15:03 Michael Peters wrote:
> This is only true if those structures were created during run time and go out
> of scope at run time.
> If they are generated at compile time or attached to global variables or
> package level variables,
> they will not be re-used by Perl.
Wait a mi
On Fri, Oct 24, 2008 at 8:57 AM, Carl Johnstone
<[EMAIL PROTECTED]> wrote:
> If you're really concerned and would rather the child process quits and
> frees additional memory to the OS, then call $r->child_terminate in any of
> your handlers, and the child process will automatically quit at the end
Carl Johnstone wrote:
Something else I will do for my low-usage but "massive" scripts (those
that have large memory structures and take several seconds to execute)
is to place these in a non-mod_perl directory so I can be assured their
memory usage goes away at the end of the response.
I was referring to script initialization (responding to that first request)
and not the httpd daemon startup. Really, the only "startup" that should be
slower is when the whole httpd service is restarted (such as at server
startup) since it would have to preload all modules for all standby da
--- On Mon, 10/20/08, Carl Johnstone <[EMAIL PROTECTED]> wrote:
> From: Carl Johnstone <[EMAIL PROTECTED]>
> Subject: Re: Reducing memory usage using fewer cgi programs
> To: "Michael Peters" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Cc: modperl@perl.apache
I also use a PerlRequire startup.pl to preload most modules (CGI, DBI),
but I thought that was only for quicker startup times and not for sharing
memory. Is that correct?
Preloading helps with speed (you don't get the the initial loading hit for
a module the first time it's used in a specific
--- On Fri, 10/17/08, Michael Peters <[EMAIL PROTECTED]> wrote:
> To think about how this works under mod_perl, pretend that
> all of your scripts are put together into
> 1 larger script and all those "use" statements
> are repeated. Does having multiple "use CGI"
> statements make your script us
Thomas Hilbig wrote:
I have about a dozen small cgi programs under mod_perl2 that all pretty well
look like this..
use CGI;
use DBI;
use perlchartdir ; # graphing
To think about how this works under mod_perl, pretend that all of your scripts are put together into
1 larger script and all t
I have about a dozen small cgi programs under mod_perl2 that all pretty well
look like this..
use CGI;
use DBI;
use perlchartdir ; # graphing
fetch parameters
build SQL and fetch data from database
build graph image from data
send image
Under mod_perl, will the memory footprint of the lib
16 matches
Mail list logo
