[gambit-list] Help With Memory

Joel J. Adamson <adamsonj@email.unc.edu> adamsonj at email.unc.edu
Tue Sep 23 09:25:20 EDT 2008


Thanks for all the replies so far --- Gambit's user community is the
best I've found for any Scheme implementation.

Update on my thinking about this problem: I think that if I am adding
more iterations (which is all I'm doing by tweaking my parameters), the
program should just take longer to run, but that's not what happens.  

>>>>> "DR" == David Rush <kumoyuki at gmail.com> writes:

    DR> You can write spaghetti code in any language. The same applies
    DR> to memory leaks :)

Good point: my frustration was making me think "Maybe what they say
about Common Lisp is true," but then I realized "whatever crappy coding
I'm doing I can do just as crappy in Common Lisp, C, Python, even Perl
--- I'm a multilingual programmer..."

    DR> After skimming your code, I see nothing obvious; however, there
    DR> are definitely some areas that deserve a closer look:

    DR> 1) Your cartesian product code could potentially use *tons* of
    DR> memory.  It doesn't appear to be called from anywhere, but maybe
    DR> I'mm reading your code too fast.

The data structure produced by `Cartesian' just sits there and gets read
--- it doesn't grow and it doesn't get passed to anything --- could it
still be getting copied?

I could certainly find a better way to derive the parameters for each
run at the beginning of each run instead, e.g., reading the data into a
hash-table, or reading the file at each run.  Which would be more
efficient (in terms of not crashing my program)?  Time is not really an
issue, it's getting the program to finish.

    DR> 2) your use of call/cc in the fitness function appears
    DR> gratuitous

The fitness function is not recursive in the current version, but I
could certainly find a better way to exit.  I will point out that this
is the sort of thing that beginner texts say call/cc is perfect for ---
the typical example being applying `*' to a list and use call/cc to exit
when you hit a zero.

    DR> The thing to remember about call/cc is that it potentially can
    DR> duplicate large portions of the stack. 9 times out of 10 you
    DR> will be better off writing your code to using explicit CPS,
    DR> anyway. (Less filling! Tastes Great!)

Hmmm...okay, then I'm getting more mixed messages about call/cc.  I know
I've read in more than one place that "any program written in CPS can be
rewritten more efficiently using call-with-current-continuation..."  I'm
not blaming anybody: I want to know who to believe.  I'll certainly
believe a well-phrased argument for compelling use of CPS from the gambit-list.

    DR> Have you traced this program to see where it's allocating
    DR> heavily?

What's the best way to do that?  I've traced certain functions and they
work the way that I expect.  Is there way to trace the entire call
stack, as insane as that might look?

Thanks a heap ;)

Joel

-- 
Joel J. Adamson
University of North Carolina at Chapel Hill
CB #3280, Coker Hall
Chapel Hill, NC 27599-3280

Before you reply to this email, please read
http://www.unc.edu/~adamsonj/email-howto.html



More information about the Gambit-list mailing list