Joe Marshall  <jrm@ccs.neu.edu> wrote:
+---------------
| Kent M Pitman <pitman@nhplace.com> 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

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607