(Thanks for the alert about my mail!) > On Fri, Jan 29, 2010 at 12:27 PM, Carl Eastlund <c...@ccs.neu.edu> wrote: > > One, there are some functions that I memoize with a weak hash table. > > Are there any sorts of values that will never be collected, and will > > persist forever in the hash table? For instance, do word-sized values > > like fixnums or ASCII characters stick around?
Fixnums are the only true special case. Some other values are difficult to reason about: * Latin-1 characters are always reachable, because they are `eq?' when they're `equal?', and there's a table that refers to all of them. * Constants like `#t', `#f', `(void)', `eof', etc. are always reachable from somewhere. * Interned symbols are GCed, but you can't generally predict whether anyone else is using a given symbol. * Some common flonums like `+inf.0' are semi-interned; a primitive that produces `inf.0' might always produce the same one in the sense of `eq?'. More generally, non-fixnum numbers are a lot like symbols, it in that someone else might hold onto one for some reason. * A quoted value stays reachable as long as the code is reachable for the expression that produced it. Of course, weak references usually work best on the results of functions that offer a guarantee of allocation, such as `list' (documented) or `cons' (not documented; oops). When I put my compiler hat on, I'm not always happy with allocation guarantees, but weak references are why they're (supposed to be) documented. > > Two, I've gotten the impression that special casing variable-arity > > functions at some fixed arities via case-lambda will speed up the > > common case. Is this true, Yes, typically. > and if so how significant is the > > difference (as a general order of magnitude)? The potential improvement is mostly in avoiding a list allocation for the rest argument and then pulling values out of that list. > > Is there some cutoff > > past which this specialization no longer pays off? I know there's no > > a priori precise answer, I'd have to experiment for that, but if > > there's a representation change (e.g. functions calls with more than 8 > > arguments get allocated as lists regardless) it would be useful to > > know. There's no such cut-off. A list is never created for function arguments unless you use a rest arg. So, the trade-off is list creation versus the number of cases to check and the extra code for each case. As a minor complication, a list is not created for a rest argument if the argument identifier isn't used in the procedure body (after the optimizer's simplifications). Another complication is that the compiler doesn't currently inline applications of `case-lambda's. It should, and maybe it will soon. As of a few days ago, the compiler also didn't inline applications of a procedure with rest args, but now it does (because I found a use that needed it). _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
