Subject: Re: basic question (probably w/ no good answer)
From: (Rob Warnock)
Date: 2000/04/09
Newsgroups: comp.lang.lisp
Message-ID: <8cojod$1gq6f$>
Erik Naggum  <> wrote:
| Rob pointed out that releasing the hold on the objects might help
| (again, metaphorically) the garbage collector pick up dead objects
| earlier, although it is hard for me right now to imagine how this
| could be affected: scope analysis would cause the bindings to go out
| of scope either way, and if these variables were in call-frame slots
| or registers, they wouldn't necessarily be any more garbage unless
| these slots were explicitly set to nil or something similarly drastic
| (because the savings would be so limited compared to the cost of doing
| this all over the place).

I was thinking more low-tech, I guess, of (metaphorically) helping the
garbage collector get rid of large intermediate temporaries as soon as
possible, especially if you "knew" you were about to do some more heavy
allocating immediately after the LET block. Quickly-contrived example
[sorry, I don't know the standard CL function for "tree-flatten" a.k.a.

	(defun foo (big-data-structure1 big-data-structure2)
	  (let (tmp3)
	    (let* ((tmp1 (map-tree #'some-func big-data-structure1))
	           (tmp2 (map-tree #'some-func big-data-structure2)))
	      (setq tmp3 (reduce #'+ (mapcar #'some-scoring-func
					     (tree-flatten tmp1)
					     (tree-flatten tmp2)))))
	    ;; At this point, tmp1 & tmp2 are garbage, and any GC triggered
	    ;; by the following allocation will be able to use the reclaimed
	    ;; space and perhaps not have to expand memory.
	    (memory-grabbing-func tmp3)))

Yes, I know that re-writing the whole thing in completely functional style
would do exactly the same thing:

	(defun foo (big-data-structure1 big-data-structure2)
		(tree-flatten (map-tree #'some-func big-data-structure1))
		(tree-flatten (map-tree #'some-func big-data-structure2))))))

but when you're writing/debugging incrementally, you sometimes want those
intermediates available for inspection/printing, and then somehow you never
seem to get around to rewriting into functional purity...


Rob Warnock, 41L-955
Applied Networking
Silicon Graphics, Inc.		Phone: 650-933-1673
1600 Amphitheatre Pkwy.		PP-ASEL-IA
Mountain View, CA  94043