Hi,

"Jared Whiting" <[EMAIL PROTECTED]> writes:

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

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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to