On 8/15/05, Jared Whiting <[EMAIL PROTECTED]> wrote:
> machine because in the process of creating images the GIMP keeps holding
> on to more and more memory.  As an example, I can run the following

> $img->gimp_image_undo_enable;
> gimp_image_delete($img);
> Gimp::end;

> the GIMP instance grabs on to more memory and holds on to it
> permanently.  Deleting the image and disabling undo do not result in the
> GIMP releasing memory for the new layer it created.  I would prefer not

What about putting "$img = undef;" at the end -- does this change anything?

Also, in the Perl Docs, "perlfaq3":


How can I free an array or hash so my program shrinks?

(contributed by Michael Carman)

You usually can't. Memory allocated to lexicals (i.e. my() variables)
cannot be reclaimed or reused even if they go out of scope. It is
reserved in case the variables come back into scope. Memory allocated
to global variables can be reused (within your program) by using
undef()ing and/or delete().

On most operating systems, memory allocated to a program can never be
returned to the system. That's why long-running programs sometimes re-
exec themselves. Some operating systems (notably, systems that use
mmap(2) for allocating large chunks of memory) can reclaim memory that
is no longer used, but on such systems, perl must be configured and
compiled to use the OS's malloc, not perl's.

In general, memory allocation and de-allocation isn't something you
can or should be worrying about much in Perl.

See also ``How can I make my Perl program take less memory?''


How can I make my Perl program take less memory?

When it comes to time-space tradeoffs, Perl nearly always prefers to
throw memory at a problem. Scalars in Perl use more memory than
strings in C, arrays take more than that,
[I suggest you read the entirety of this question in the actual FAQ,
it might be helpful.]


Hope this helps.

 - Just my two cents
 - No man is an island, and no man is unable.
Gimp-developer mailing list

Reply via email to