[mcclim-devel] how to track down apparent memory leaks in drawing?

[John Morrison]

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


-- 
--- John Morrison
--- john.nmi.morrison at gmail.com