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