I am currently using GIMP 2.8 for GNU/Linux, Gimp Perl 2.0 with Pango 1.10. I'm using a cgi to dynamically generate images through the Perl Server and in general it works very well.

Currently we do need to restart the GIMP instance and perl server on the 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 script:

use strict;
use lib qw(/www/lib/perl);
use Gimp qw(:auto);

Gimp::init; my $img = gimp_image_new(300, 200, 0); $img->gimp_image_undo_disable;

my $layer = gimp_layer_new($img, 300,200,RGB, "Layer 1", 100, NORMAL_MODE);
gimp_image_add_layer($img, $layer, -1);

my $text_layer = gimp_text_fontname($img,-1,0,0,"111111111111", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER);

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

If I add a new text layer in the script above and rerun it, I see that 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 having to restart GIMP and its perl server so I'm looking to see if there is anything else I can do to force it to free up memory.

Thanks, Jared

_________

... meant to write GIMP 2.2.8

-----Original Message-----
From: Sven Neumann [mailto:neo@gimp.org] On Behalf Of Sven Neumann Sent: Tuesday, August 16, 2005 2:09 PM To: Jared Whiting
Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Gimp_image_delete and adding text layers

Hi,

"Jared Whiting" writes:

I am currently using GIMP 2.8 for GNU/Linux,

There is no such GIMP version (yet). What version are you really using?

Sven

How much memory increase do you see per image? Can you run this script a couple of times and show us memory usage before and after?

Sven

When I first start up GIMP:

/usr/bin/gimp -d -i -c --batch '(extension-perl-server 1 0 0 )'

I see the following using top (script-fu and Perl-Server processes never change so I'm not including those):

VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18440 7444 13m S 0.0 1.4 0:01.07 gimp

Then I execute the code shown at the end of this message, and I see the following:
VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18648 8056 13m S 0.0 1.6 0:01.12 gimp

Within the code I add an additional text layer and use gimp_merge_down, and see no change. I add seven text layers and still no change (I had originally thought adding a new text layer ALWAYS results in more memory being taken but this is not the case, so my initial description of the problem is misleading.) After running the script with the new text layers about 25 times in rapid succession I see the following:

VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18788 8196 13m S 0.0 1.6 0:06.23 gimp

This behavior occurs with this sample pretty consistently. Not a huge increase, but the cgi I'm using in production does a lot more than this and can be generating a few thousand images in one day.

Thanks, Jared

> Are any of these concurrently, and if so how many; could this

make a difference?

~Mike

In production there can definitely be concurrent image generation, which might be playing a role in the issue I'm having there with increased memory. With the test code though I'm just running the script many times in sequence.

Thanks,
Jared

top isn't actually a very accurate way of profiling memory usage. The numbers you have shown so far can easily be explained by memory fragmentation and the fact that glibc allocates memory in pools. Smaller memory fragments are not returned to the operating system but are being kept for reuse in the application. Please run your script a lot more often and see if there's a significant increase in memory.

Sven

I have a test script that does the following:

Gimp::init; my $img = gimp_image_new(300, 200, 0); $img->gimp_image_undo_disable;

my $layer = gimp_layer_new($img, 300,200,RGB, "Layer 2", 100, NORMAL_MODE);
gimp_image_add_layer($img, $layer, -1); my $text_layer = gimp_text_fontname($img,-1,0,0,"111111111111", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER); my $text_layer2 = gimp_text_fontname($img,-1,0,10,"2222222222222", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer2, CLIP_TO_BOTTOM_LAYER); my $text_layer3 = gimp_text_fontname($img,-1,0,20,"3333333333333", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer3, CLIP_TO_BOTTOM_LAYER); my $text_layer4 = gimp_text_fontname($img,-1,0,30,"44444444444444", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer4, CLIP_TO_BOTTOM_LAYER); my $text_layer5 = gimp_text_fontname($img,-1,0,40,"555555555555555", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer5, CLIP_TO_BOTTOM_LAYER); my $text_layer6 = gimp_text_fontname($img,-1,0,50,"66666666666666666", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer6, CLIP_TO_BOTTOM_LAYER);

$img->gimp_image_undo_enable; gimp_image_delete($img);

Gimp::end;

This script gets run 5000 times in a loop, and it's the only script accessing the gimp instance. I see no change in the perl-server and script fu processes, but I do see an increase for gimp. I'm not sure how significant the increase is as I have to run the script quite a bit, but this is what I see after running several loops and using top after each loop:

Start up:
VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17632 7448 13m S 0.0 1.4 0:01.14 gimp

Loop 1: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21088 11m 13m S 0.0 2.2 11:45.59 gimp

Loop 2: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25544 14m 13m S 0.0 2.9 23:28.40 gimp

Loop 3: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27796 17m 13m S 0.0 3.5 35:11.54 gimp

Loop 4: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31408 21m 13m S 0.0 4.2 46:54.84 gimp

Loop 5: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 35220 24m 13m S 0.0 4.8 58:35.12 gimp

Loop 6: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 38108 27m 13m S 0.0 5.5 70:11.92 gimp

Loop 7: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 42292 31m 13m S 0.0 6.2 81:51.41 gimp

Thanks, Jared