Gimp_image_delete and adding text layers
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| Gimp_image_delete and adding text layers | Jared Whiting | 06 Sep 20:55 |
| Gimp_image_delete and adding text layers | Sven Neumann | 06 Sep 21:25 |
Gimp_image_delete and adding text layers
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 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 gimpLoop 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_image_delete and adding text layers
Hi,
"Jared Whiting" 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
