3 ms·

> I hate to be "that guy," but what happened to the Guile-Emacs project? Guile performs way better than Elisp too I’m sorry to be that guy, but did you ever tr

> I hate to be "that guy," but what happened to the Guile-Emacs project? Guile performs way better than Elisp too I’m sorry to be that guy, but did you ever try it out for yourself? Just starting Emacs took as long as a full regular Emacs elc-build, if not longer. So not exactly faster by a universal standard.

fusiongyro 8y ago
Guile being faster at running Elisp doesn't necessarily mean that Emacs + Guile is faster than Emacs. Is that why the project stalled out?
- josteink 8y ago
  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.
deleted 8y ago
[deleted]
nerdponx 8y ago
How did swapping out the Elisp interpreter for a Guile interpreter hurt performance so bad? Seems like it should be a pretty benign change.
- messe 8y ago
  Emacs pre-compiles byte code, I'd imagine that the guile version didn't do that by default.
- tame73_binds 8y ago
  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.
jpfr 8y ago
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 http://git.savannah.gnu.org/cgit/guile.git

fusiongyro 8y ago

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

josteink 8y ago
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.

deleted 8y ago

[deleted]

nerdponx 8y ago

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

messe 8y ago
Emacs pre-compiles byte code, I'd imagine that the guile version didn't do that by default.
tame73_binds 8y ago
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.

jpfr 8y ago

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 http://git.savannah.gnu.org/cgit/guile.git