Re: [MacPerl] Memory problems in OO context

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

On Mon, 6 Dec 1999, Chris Nandor wrote:

> No, CPAN.pm takes about as much memory on other systems, too, under the
> right conditions.  There may be a leak, but CPAN.pm takes a ton of memory.

Okay.  I was wrong about CPAN.pm needing more memory, at least for the
case where you force Perl to use Archive::Tar and Compress::Zlib.

> there.  Doing it again without quitting the CPAN shell, and memory use
> jumps to 31MB and stays there.  This is similar to what happens under
> MacPerl.  So I'd say there may be a leak, but it is with Archive::Tar or
> Compress::Zlib (or both), not with CPAN.pm, and not with MacPerl.

This actually reinforces one point I was trying to make.  I really haven't
been blaming MacPerl for the memory leak.  I don't know where it is, and I
really don't care whose code is responsible, as long as I can fix it or
work around it.  I _am_ trying to whittle down my code and find the
bugger, but that is very difficult with a memory leak:  unlike other bugs,
it usually isn't at one place in code, but in at least two places
separated far enough or obscured enough that you don't associate the two
together. (Otherwise you'd have recognized and fixed the leak, right?)

The presence of leaks in various modules, or the suspicion that there are
leaks but no proof, reinforces the point that Perl or at least MacPerl
needs (some|more) leak-proofing tools.  And as I've said, this is ironic
given Perl's garbage collecting.  Not as ironic as Java, which has made
much ado over the garbage collection issue, but still ironic.

I'm looking for tools to help me in this search.  It sounds like MacsBug
may be the best shot right now.

--
MattLangford 


# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org