🚀 go-pugleaf

re: >>>>> "Brad" == Brad Miller <miller@cs.rochester.edu> writes:

      Brad> This is in general true, and why Lisp tneds to be a nice language 
      Brad> for exploratory programming. However, once you are trying to 
      Brad> optimize a program and actually make it efficient at runtime, it 
      Brad> is always cheaper for an application to explicitly free memory 
      Brad> than it is for the gc to do it. What would be really nice is to 
      Brad> have, as on the lisp machine, areas of memory (heaps) that are not
      Brad> gc'd, but must be explicitly freed by the programmer.

    *Always cheaper* ?! I think there are a couple of people, Ben Zorn in
    particular, who would claim that automatic garbage collection is better
    than explicit memory management. Here are three arguments I can think of
    where GC could win:
    1) The cost of calculating when to free memory could be cheaper.
    2) Memory compaction.
    3) The elimination of memory management errors.

    In short, I'm not so sure the issue is that cut and dried.

At the 1992 ACM Lisp & Functional Programming Conference, Will CLinger
had to stand up and rebut this "urban myth" about explicit storage
reclamation always being faster (it had been repeated in one of the
technical papers presentations).  Will, a Professor at University of
Oregon and a long time Wizard of SCHEMEology, alleged to be writing a
paper on just this topic.

In fact one of the most interesting bugs I ever saw logged against the
Lucid Common Lisp system was: "GC runs to fast"!!!   It seems that the
end user had an application that would create hundreds of thousands of 
little particles of data and "drop them on the floor" all within the space 
of a couple seconds (these were intermediate expression temporaries), and 
this process would go on for several minutes in a row.  Of course, about 
every few seconds or so, an "ephemeral" or "generational" scavenge would 
be invoked, and by careful monitoring the user discovered that each such 
scavenge was taking much less than 25 milliseconds (on a SparcStation; 
maybe an SS2?).  Since it was manifestly impossible to "reclaim" the 
nearly one megabyte of garbage in just a few milliseconds, he figured 
that the GC wasn't actually performing its work.


But that's the beauty of "generational" style collectors!


If you need more convincing about this topic, just try calculating how 
long 200,000 calls to _free would take in C.  Or, wait for Will's paper.



-- JonL --