The guile-emacs branch afaik did not use precompiled byte-code. So startup took ages.

Guile itself is making huge progress. There's ongoing work for JIT compilation as well. Andy Wingo drives this work. And he brings a lot of experience from work on the V8 Javascript engine.

I see no technical reason why guile-elisp should be any slower than normal elisp. It's just that some of the optimizations have not yet been put into place. After a switchover all the improvements from Guile will come for free in the future.

See the branches named "master", "lightning" and "wip-elisp" here: http://git.savannah.gnu.org/cgit/guile.git

Guile being faster at running Elisp doesn't necessarily mean that Emacs + Guile is faster than Emacs. Is that why the project stalled out?

I think it was issues improving startup performance + largely that it was a one man show.

It doesn’t take much to terminally derail an effort driven by only a single contributor.

How did swapping out the Elisp interpreter for a Guile interpreter hurt performance so bad? Seems like it should be a pretty benign change.

The work isn't finished, it runs but that's it. Comparisons aren't meaningful in the current state. Besides the bytecode thing, there was also an issue with string conversions that afair wasn't solved.

Emacs pre-compiles byte code, I'd imagine that the guile version didn't do that by default.