Re: [Gimp-developer] Gimp Conference 2006

[Roman Joost]

Hi David!

On Sun, Sep 04, 2005 at 08:20:44PM +0200, David Neary wrote:
 Come to Lyon for the GIMP Conference, 2006!
I hope I can make it. I'm really glad that you guys are organizing again
a GimpCon :)

Hopefully see you in Lyon!
-- 
Roman Joost
www: http://www.romanofski.de
email: [EMAIL PROTECTED]


pgpBF5wY3C1s0.pgp
Description: PGP signature

RE: [Gimp-developer] Gimp_image_delete and adding text layers

[Jared Whiting]

 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


Jared Whiting [EMAIL PROTECTED] wrote:
 This script gets run 5000 times in a loop, and it's the only script
 accessing the gimp instance.
 ...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


Is there any more information I can provide regarding my test script and
the memory increase I observe with GIMP?  Following your advice I ran my
script more often, but I'm not sure if my response was what you were
looking for.  If I run a script that creates a new image with six text
layers in a loop it results in about a 3000k increase in the amount of
memory the GIMP process is holding on to for each 5000 times the script
gets executed (as observed using top).  There is only a single instance
of the script being executed at any time.

This behavior is similar to what I have observed in our more complicated
script we use where small but permanent memory increases occur over
time.  I am open to the idea that there is no memory leak and that it's
a problem with my script or that I'm providing unreliable/inadequate
info regarding the issue so let me know if that's still the case. 

I mainly am looking for enough insight so I don't have to rely on having
to restart GIMP for our image generation scripts unless it's absolutely
necessary.

Thanks,
Jared










___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp_image_delete and adding text layers

[Sven Neumann]

Hi,

Jared Whiting [EMAIL PROTECTED] writes:

 Is there any more information I can provide regarding my test script and
 the memory increase I observe with GIMP?  Following your advice I ran my
 script more often, but I'm not sure if my response was what you were
 looking for.  If I run a script that creates a new image with six text
 layers in a loop it results in about a 3000k increase in the amount of
 memory the GIMP process is holding on to for each 5000 times the script
 gets executed (as observed using top).  There is only a single instance
 of the script being executed at any time.

3MB for 5000 executions of your script doesn't look like we'd be
leaking image tiles. We might leak some smaller structures that are
allocated during the execution of the script. What you could do is run
gimp in a memory profiler like valgrind (http://valgrind.org/). Use a
command-line like

 valgrind --num-callers=24 --leak-check=yes --error-limit=no gimp

You will need more memory than usually to run valgrind and you should
also use a fast machine. Otherwise things will become incredibly slow.
Start by running your script once, then quit gimp. valgrind should
then leaked memory. A few hundred bytes of leaked memory are normal.
These are being lost in libraries used by gimp and the memory lost
here is constant and only allocated on initialization. Every leak in
gimp should be reported though.

If you don't find any leaks this way, we have to assume the problem is
memory fragmentation. We could then try to figure out if there are
ways to avoid this problem (for example by using GLib memchunks).


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer