Subject: Re: novice: mapcan use?
From: (Rob Warnock)
Date: Fri, 02 Sep 2005 02:41:06 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Joe Marshall  <> wrote:
| Kent M Pitman <> writes:
| > However, I think it's pretty clearly wrong to think that consing doesn't
| > matter, so even if you start thinking that you want to do some style that
| > prefers non-destructive over destructive, I don't think that means you're
| > suddenly free of the cost of gc and consing.  In both styles, you still
| > have to worry about storage wastage, about intermediate expression swell,
| > etc.
| Consing doesn't matter as much as it used to.  There's no longer a
| need to watch your allocation like a hawk(inson).
| Of course, you can always slow things down by *excessively* depending
| on the GC.

Generational GCs that use Ungar's trick of a fixed-location "nursery"
typically find that the best nursery size is roughly the size of the
secondary cache [or in more recent CPUs, the tertiary cache or whichever
one is just before main memory!]. One assumes that the GC designer will
have done their job right, and initialized the size of the nursery
dynamically based on the cache size of the currently-running platform.

In which case, the best strategy for the user [meaning programmer]
is to try to arrange that the vast majority of intermediate storage
consed is garbage by the time a nursery-size worth's has been consed,
whereupon almost none of the data in the nursery is still "live" at
the next minor GC. Hence allocations & minor-GCs keep using the same,
cached(!) address range over & over...

In that context, note that "fresh" consing is often cheaper than
"mutating" recently-consed objects [the latter requiring a range
check to consider (and reject) adjusting the "remembered set"], but
the former will use up space in the nursery faster and trigger more
minor GCs. Hence which one is better "just depends"... as always. ;-}


Rob Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607