The memory number you need to worry about is peak usage. Perl hangs on to any memory the system gives it, and doesn't let go till the perl process ends. That has major importance for long-running processes, as with mod_perl and other daemons.
To expand further on this one, this is actually the operating system's fault. In *nix, a process address space can only be extended. I believe the same is true in Win32 systems, unless specialized APIs are used (which nobody uses anyway ;)
(BTW, ++ to Zaxo)
Regards.
-lem
| [reply] |
Good points but one question. I was under the impression that Perl normally hangs onto the last pad values as an optimization. Is this only in subs or does this happen with all scopes? I think it does hang on to them or I don't think the my $x if 0 behaviour would occur. If this is the case and you have very large lexical data structures I would think you would want to explicitly undef them at the end of the scope.
-Lee
"To be civilized is to deny one's nature." | [reply] |
There's only one pad per subroutine, so it's per-sub.
| [reply] |
Excuse my ignorance,
I maybe just reading your answer the wrong way but
from perlguts
So each subroutine is born with an array of scratchpads (of length 1). On each entry to the subroutine it is checked that the current depth of the recursion is not more than the length of this array, and if it is, new scratchpad is created and pushed into the array.
-Lee
"To be civilized is to deny one's nature."
| [reply] |