Lightening run-time code generation
wingolog.org
wingolog.org
I wonder why Andy didn't chose to write the JIT in Guile itself, with a binding to Lightening, rather than in C. Guile is designed to be embedded and have bindings written for it.
OP states "eventually I should be migrating this code over to Scheme anyway. And, of course, simple can mean fast, and I needed fast code generation.". That does not anwer you actual question (and neither does the article), but I gather this was to make the project finite (solve one and only one problem only at a time), not because the author was not aware.
That is especially nice when writing complex macros. I remember writing a loop utility and realized I couldn't run the optimizer on code where everything was known at compile time, since guile usually optimized the loop away. (for/sum ((i (in-range 5)) i) expanded into 20 lines of code, but optimized to the integer 15 :)
Both chez and guile usually produces proper error sites, so it is done in some fashion.
In terms of performance, you have a point. However, there are many ways to set the performance dial, depending on your particular cost/benefit situation.
When Racket (nee PLT Scheme) added JIT on x86, via GNU Lightning, there was a very noticeable practical performance bump for some of my work (dynamic Web serving).
The peg parser and my implementatio of clojure's transducers get the biggest performance improvements. My simple CSV parser got over 3x faster without any changes on my part.
It is slow as molasses though. A 5mb CSV file takes roughly 12s on 2.2. A properly implemented streaming parser should be several orders of magnitude faster. I want to see, just for shits and giggles if it is possible to beat pythons CSV parser with a pure guile module. I think it is. With guile 2.9 it should be a walk in the park.