Re: Tracking Memory Leaks
by dragonchild (Archbishop) on Aug 14, 2001 at 22:19 UTC
|
| [reply] [d/l] |
|
Heh, well, we do all those things, but they should be controlled.
- Yes, in various places, but they should all be limited in one way or another (either they go out of scope at various points or they only have a limited number of elements in them).
- We do have one module that uses circular references, but using Weakref, that shouldn't be a problem.
- Yes, scoping on the project is very tight.
- This is the thing that I'm worried about. We're constantly loading new classes, dymanically created from database information. Now, theoretically, we have a finite number of classes, so the memory usage from loading these things should be finite itself (and that limit should be hit rather quickly). However, I'm not positive this is the case. Anyway know much about the finer points of this?
- No.
Thanks for the help.
| [reply] |
|
| [reply] |
|
|
|
|
We're constantly loading new classes, dymanically created from database information. Now, theoretically, we have a finite number of classes, so the memory usage from loading these things should be finite itself (and that limit should be hit rather quickly). However, I'm not positive this is the case. Anyway know much about the finer points of this?
Are you cleaning up the symbol tables after you're done using these new classes, or are they being re-used? We found in Class::Prototyped that each new class takes up around 1.5-2K of memory; more (of course) with methods. You can clean up the symbol table when you're done with code like this (assumes $package does not contain '::'):
no strict 'refs';
foreach my $key ( keys %{"$package\::"} ) {
delete ${"$package\::"}{$key};
}
# this only works because we're not a multi-level package:
delete( $main::{"$package\::"} );
| [reply] [d/l] |
Re: Tracking Memory Leaks
by koolade (Pilgrim) on Aug 14, 2001 at 22:40 UTC
|
$VAR1 = \$VAR1;
or
$VAR1 = [ $VAR1 ];
or
$VAR1 = { key => $VAR1 };
Then you know you have something to fix.
Also, I've experienced a few problems w/ memory leaks in perl 5.6.0 and linux. e.g.:
eval "use Any::Module";
Leaks memory for me, and doesn't appear to with 5.6.1. But I haven't done enough testing to be definitive about that. Someone else might be able to tell you more about this.
| [reply] [d/l] [select] |
Re: Tracking Memory Leaks
by perrin (Chancellor) on Aug 15, 2001 at 04:23 UTC
|
You should keep in mind that when lexical variables go out of scope, the memory used by them is NOT reclaimed by Perl. This is an optimization, assuming you will use the lexicals again. If you don't want this behavior, you can explicitly set the variables to undef when you're done with them, which will free their memory.
Are you doing anything with subroutine references? It's possible to chew up RAM by using things like Error.pm's try/catch syntax if you aren't careful to avoid accidental closures.
You might want to check out the mod_perl guide for additional information on Perl memory management. | [reply] |
|
perrin++
Just to be clear, the memory used directly by the
lexical is not freed but if, for example, the lexical
contains the last reference to something, then that
something will be destroyed and its memory freed when the
lexical's scope is left (or when the last reference to the
lexical is destroyed). So this is mostly a problem when
dealing with long strings rather than objects.
And the bug with closures never being freed has been found
but I don't think any Perls have been released that
contain this fix.
-
tye
(but my friends call me "Tye")
| [reply] |
|
Just to be clear, the memory used directly by the lexical is not freed but if, for example, the lexical contains the last reference to something, then that something will be destroyed and its memory freed when the lexical's scope is left (or when the last reference to the lexical is destroyed). So this is mostly a problem when dealing with long strings rather than objects.
No, I don't think that's correct. The memory will not be freed, if by freed you mean "available for use by other variables in my program". It will be re-used if you use that lexical again. See
this post from Doug MacEachern for more info on this.
I'm not sure the closures thing I was talking about is really a bug; it's just a side-effect of nested subs and closures. If you do this, it will leak like crazy:
my $foo;
sub bar {
sub baz {
$foo++;
}
}
It's creating a new private copy of $foo for baz() every time. Using Error.pm can sometimes lead people to do this without realizing it, when they use nested try/catch blocks. | [reply] [d/l] |
|
|
Re: Tracking Memory Leaks
by Cirollo (Friar) on Aug 14, 2001 at 22:20 UTC
|
| [reply] |
Re: Tracking Memory Leaks
by Nitsuj (Hermit) on Aug 15, 2001 at 17:39 UTC
|
Important also is "which perl interpretter" and "which OS" different implementations and operating systems will treat garbage collection differently. Just because the perl interpretter free()'d it doesn't mean that the operating system caught that yet... but of course, if perl was maintaining its own heap, that wouldn't matter, but the interpretter would keep the memory until terminated.
IE, I know that when I run perl, it will behave like this, but what about active perl... or the interpretter that comes with matlab.
Just Another Perl Backpacker | [reply] |
Re: Tracking Memory Leaks
by Starky (Chaplain) on Aug 16, 2001 at 01:19 UTC
|
Take a look at Nick Ing-Simmons' Devel::Leak.
Hope this helps!
| [reply] |