tl:dr; never mind.

I didn't understand the circumstances of output-record generation. I needed to try harder to get the pane/stream to not record output. Works fine now (millions of drawing operations with no perceptible long-term memory use). Sorry.

-jm

On Friday 02 November 2012, John Morrison wrote:

Hi All;

tl:dr; slightly revised drawing-benchmark demo (attached) from quicklisp mcclim shows increased (leaked?) memory usage.

I am using McCLIM to deal with PostGIS (FC16, x86_64). It appeared that drawing vector GIS data using draw-line* leaked memory.

After doing the obvious things (see below), I slightly modified the clim-demo::drawing-benchmark app to try and produce the smallest code that exhibits the behavior:

1. draw lines instead of either rectangles or text
2. for 20 seconds rather than 1
3. print SBCL's (room) into the window (make your mapped window tall)
4. run a (sb-ext:gc)
5. print (room) again

lather, rinse, and repeat, by hitting the "Run" button.

I obviously didn't use the presentation system in my program (as I presumed it would hold onto output records, etc.). I commented out the single draw-line* form, and that enabled my program to traverse the entire (rather large) GIS vector dataset with no perceptible increase in memory usage (according to the "top" UNIX utility rather than (room). I updated to today's SBCL (maybe it's a bug that's been fixed), but I still observed the increasing memory usage.

Questions:

(a) Should I try any of the several forked McCLIMs mentioned recently? Has any of them had significant work in the simple drawing area?

(b) Can anybody tell me anything that might shorten the hunt?

Thanks!!!

-jm