Re: Memory issues
- From: "Peter J. Holzer" <hjp-usenet2@xxxxxx>
- Date: Sun, 30 Mar 2008 14:55:00 +0200
On 2008-03-30 09:28, jm <jm@xxxxxxxxx> wrote:
Joost Diepenmaat a écrit :[...]
jm <jm@xxxxxxxxx> writes:
Modifying a little bit again the script, and checking execution with
ltrace, I observed malloc is called 1871 times when free is just called
922 times.
Isn't it an issue?
IOW, if you
have a long-running program that only means you need 100Mb for it to
run, it does NOT mean it takes a 100Mb for each call.
Yes, it is what I observed.
But this mean it is not possible to free the memory consumed by one
function, when you know you need memory in another one function.
You can. Perl keeps around the lexical variables, but not any objects
they point to. So avoid large scalar, hash or array variables in subs
and use references instead. For example, compare the behaviour of
#!/usr/bin/perl
use warnings;
use strict;
print a(@ARGV), "\n";
exit 0;
sub a {
print "entering a @_\n";
my ($n) = @_;
my $s1 = "a" x $n;
my $s2 = "b" x $n;
my $rc = length($s1 . $s2);
print "leaving a @_\n";
return $rc;
}
and
#!/usr/bin/perl
use warnings;
use strict;
print a(@ARGV), "\n";
exit 0;
sub a {
print "entering a @_\n";
my ($n) = @_;
my $s;
$s->[1] = "a" x $n;
$s->[2] = "b" x $n;
my $rc = length($s->[1] . $s->[2]);
print "leaving a @_\n";
return $rc;
}
(And of course "length($s->[1] . $s->[2])" is (intentionally) stupid -
replace it with "length($s->[1]) + length($s->[2])")
Anyway, I've not seen a serious memory leak in perl itself in ages, and
I run perl processes that use up to 8 Gb of RAM and run for months
without issues.
This mean you have a 8 Gbytes RAM memory computer.
But if memory was used by perl in a better way, might be the same
programs might work on a 512 MBytes RAM computer.
Yes. But memory allocated to lexicals is usually the least of your
worries in this case. The overhead of typical perl data structures is
much worse. (Just this month I reduced the memory consumption of a
program from about 3 GB (which meant that it crashed sometimes, since
that's the limit on 32bit linux) to less than one GB by replacing an
anonymous array with a string (which I always had to unpack and repack
to access and manipulate the data within, which is ugly, but not really
slower than accessing the array).
hp
.
- References:
- Memory issues
- From: jm
- Re: Memory issues
- From: smallpond
- Re: Memory issues
- From: jm
- Re: Memory issues
- From: smallpond
- Re: Memory issues
- From: jm
- Re: Memory issues
- From: jm
- Re: Memory issues
- From: Joost Diepenmaat
- Re: Memory issues
- From: jm
- Memory issues
- Prev by Date: Re: Memory issues
- Next by Date: Re: Memory issues
- Previous by thread: Re: Memory issues
- Next by thread: Re: Memory issues
- Index(es):
Relevant Pages
|