Re: kkcc exceeding slowness

BW> because the mark method is a method, i can put logic into it to BW> check to see whether a blank table is being traversed and stop BW> traversing at that point. the problem seems to be that kkcc can't BW> be told this, and isn't smart enough (at least i don't think so) BW> to recognize whether it's already traversed something unless it's BW> a Lisp object -- and the subtables aren't Lisp objects. Right, kkcc keeps track of what it has seen by setting the mark bits. Non-Lisp objects don't have mark bits, so there is no way for kkcc to recognize that it already traversed a non-Lisp object. BW> i could make them Lisp objects, but this means either [1] i BW> integrate the header and the table, leading to an object whose BW> size is slightly over a power of 2 and hence its allocation is BW> difficult to manage efficiently (i assume, at least -- marcus, how BW> does mc-alloc handle this case?); Please make the tables Lisp objects. This is also important for the incremental garbage collector's write barrier. Allocation with mc-alloc is not a problem: Since the object is still smaller than PAGESIZE (typically 4k), mc-alloc will allocate it quite efficiently. -- Marcus