The usual techniques: shortcut around generic scheme_apply() for
chaperone-triggered slow path, shortcut around scheme_apply() for
application of a native-code interposition function, and shortcut
`chaperone-of?' test by trying `eq?' first.
Renamed `convert' to `pict-convert', etc., to avoid confusion
with `file/convert' bindings.
Moved out of `slideshow/pict' to `slideshow/pict-convert', because
most `slideshow/pict' clients do not need it.
adjust 'one-of/c' and 'symbols' so they just use or/c (when possible)
improve or/c's stronger check so that, in the case that or/c is
getting eq or equal contracts, or/c's stronger check is as good as
'symbols'/'one-of/c's stronger check is.
cells when searching in the tree
Two tricks: represent lists of nodes as improper lists so singleton
lists don't allocate a cons and pass around two accumulators that
correspond to the hd & tl of a path, instead of cons'ing that up
into a list and them immediately taking it apart again
measurement: when starting up drracket with
collects/drracket/private/unit.rkt and then waiting for the colorer to
finish, and then inserting an open quote right before the first open
quote in the file (and waiting again for the colorer to finish)
creates 249000 cons cells before this change and 116000 after this
change
After a little more work, I'm pretty much convinced that this was
the wrong approach and that the splaying implementation should just
change to not allocate the paths into lists at all, thus removing
the other 116k cons cells. (I plan to get to this another day;
it should not be difficult now that I roughly understand how these
things work.)
I also looked into top-down splaying and found these notes to
be illuminating:
http://digital.cs.usu.edu/~allan/DS/Notes/Ch22.pdf
They essentially convinced me that we cannot use top-down splaying
here, since the "reassembling" stage requires moving some arbitrary,
unexplored subtree from a right-child to a left-child, and thus the
left-subtree-length cannot be updated properly.
