Click here to get back home

Memory issues

 HomeNewsGroups | Search | About
 comp.lang.perl.misc    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Memory issues jm 03-29-2008
---> Re: Memory issues Joost Diepenmaa...03-29-2008
Posted by jm on March 30, 2008, 5:28 am
Please log in for more thread options
Joost Diepenmaat a écrit :
>
>> 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?
>
> Please keep in mind that perl's memory allocation strategy in general is
> optimized for longer running programs, not for one-off scripts (which
> makes sense, since one-off scripts don't usually need the performance
> gains).

I did not read this, nor in the documentation, nor in the faq.
Might be a faqmemory might be helpful?

> This means that for instance subroutines will get memory
> allocated on the assumption that they'll be called again, and will take
> about as much memory the next time.

But when a same routine is called several times, with different kind and
size of data, some times it consume lot of memory, and some other time
less memory.
If your code contains hundred of functions and twenty of them consume
200 Mbytes (in a similar way as aa in my example), then a 2 Gbytes
computer will not be enough to run it.

> This is NOT a memory leak per se, but it does mean that if you have a
> subroutine that takes 100Mb to complete, your program will take that
> memory and probably not give it back until the program ends.

I understand this. But I'd like to have the opposite feature.
Or at least one perl function to release the memory used by a function
(or a package).

> 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.

> In your test case, don't assume that just because the regular expression
> replacements don't in theory *need* to use any additional RAM, they
> won't. Especially not if you're using UTF-8 encoded strings (which you
> are). Perl algorithms tend to exchange RAM for speed in most cases
> anyway, and replacing a match with a new string of exactly the same
> length in bytes in a unicode string is a pretty uncommon use-case, so
> it's likely not optimized.

I do not think the issue is here.

> 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.






Posted by Peter J. Holzer on March 30, 2008, 8:55 am
Please log in for more thread options
> Joost Diepenmaat a écrit :
>>> 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

Posted by Joost Diepenmaat on March 30, 2008, 9:17 am
Please log in for more thread options

>> 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.

16 Gb, actually.

> But if memory was used by perl in a better way, might be the same
> programs might work on a 512 MBytes RAM computer.

No, because the data structures stored in the program really takes up
that much memory (though memory usage could concievably be reduced, if
we really needed to, but that's not a top priority for us). The tradeoff
here was also: speed vs memory use, and speed really was the top
priority (which also means significant pieces of the program are
actually written in C++).

The point being, these programs handle LOTS of data and run for months
without leaking - their memory use is about as stable as you'd expect. A
real leak is where repeated operation will continually increase the
amount of memory needed, which isn't what your test case is doing, and
as I said, it's not something I've seen (in the perl interpreter) in
quite a while.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

Posted by Peter J. Holzer on March 30, 2008, 8:40 am
Please log in for more thread options
>> 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?
>
> Please keep in mind that perl's memory allocation strategy in general is
> optimized for longer running programs, not for one-off scripts (which
> makes sense, since one-off scripts don't usually need the performance
> gains).

Or maybe it is optimized for one-off scripts? One-off scripts rarely
need to worry about hogging memory and it is certainly faster to let the
OS free all the memory at once than to call free a gazillion times.

        hp

Posted by Joost Diepenmaat on March 30, 2008, 9:10 am
Please log in for more thread options

> Or maybe it is optimized for one-off scripts? One-off scripts rarely
> need to worry about hogging memory and it is certainly faster to let the
> OS free all the memory at once than to call free a gazillion times.

True enough. In any case, as others mentioned, the perl interpreter is
pretty wasteful with memory in most cases where it could trade off
between speed and memory efficiency.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

Similar ThreadsPosted
Huge Memory Load for reading into memory November 6, 2006, 7:10 pm
Get Win32 Total Physical Memory & Available Physical Memory stats October 26, 2004, 10:48 pm
2 issues with "tie" August 26, 2007, 9:32 pm
DBI Performance Issues August 25, 2006, 10:33 am
Perl script issues - Need help January 20, 2005, 9:54 pm
Known issues with Perl under Cygwin? August 26, 2005, 6:43 pm
Perldoc security issues September 12, 2005, 2:16 pm
having issues using awk and/or converting to perl January 9, 2006, 6:21 am
taint issues in utf8_heavy.pl August 23, 2006, 7:43 am
Inline replacement issues October 18, 2006, 3:53 pm

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap