Make it faster

[mbrock]

it takes a while to run the web demo screen that renders a bunch of S-expressions

the low-hanging fruit solution is not to do any kind of optimizing compilation of the code

rather it's about evaluating the code in a less wasteful and silly way

two main possibilities

• convert code from lists to vectors
• optimize the use of continuations in normal control flow

[mbrock]

the way I implemented continuations is very naïve, intentionally, because I wanted to see for myself how that would affect performance—and now I have a visceral sense for it!

maintaining the continuation data structure ends up dominating the runtime because it's involved in almost every single step of evaluation... well, that's almost by definition of evaluation step...

anyway, there's no real reason to have these immutable linked list structures for the continuation context... a contiguous stack will be fine!

it will be interesting to see how big this change will be...

so the ktx structure will be revamped: instead of a hop pointer to the next frame, frames will be adjacent in memory

maybe a ktx will be an index into a new non-vat data area in the heap, an array of growable stacks, similar to v08 and v32

hmm, the frames also point to growing lists, the accumulators for funargs and bindings: should those also be part of the contiguous stacks? probably, yes; that's part of the waste now

[mbrock]

yay I made it a lot faster just by using mutable continuations and fixing the macroexpander to expand more stuff that was incorrectly being left unexpanded

closing this issue because it's good enough for now but maybe later we'll have to improve performance of argument handling