On Mon, 15 Nov 2004, John Cliff wrote:
Did manage to get IS using in excess off 200Mb of memory tho. If you open a large file (keys and mouse is a good one) then grab everything, and move it round lots, (by keys is good) you can literally watch the memory get gobbled up. (maybe as the undo list builds up?) every move was adding a coulple of meg to the IS memory usage stat.
Probably the undo list, yes. The full before and after text for each attribute change is saved (and due to compensation and style changes, there are several for each object). Multiplied by the number of objects in keys.svg, that's got to be a healthy amount of memory.
It's not as bad as it could be: using the garbage collector I've implemented aggressive sharing of string data within the repr code (which includes undo). In the pre-gc days we used to make separate copies everywhere.
The worrying thing was it didnt seem to free when i shut that doc, only when i shut the app.
There may be another refcount leak, or the garbage collector may simply not have run a collection pass yet--absent an explicit request, it only garbage collects every so many bytes allocated.
From gdb, you should be able to force a garbage collection by suspending
the process and issuing:
call GC_gcollect()
at the gdb prompt.
Be aware though that because of memory fragmentation, even once we fix the issue you won't see a full 100% of the blocks used returned to the OS (although they can be internally reused), at least until the process exits. This is true of all allocators, both standard malloc and the boehm collector's alike.
-mental