Re: guile and emacs and elisp, oh my!

[Tom Tromey <tromey@redhat.com>]

>>>>> "Karl" == Karl Fogel <kfogel@red-bean.com> writes:

Karl> Andy Wingo <wingo@pobox.com> writes:
>> I would humbly submit that you have, over time, restricted the range of
>> programs that you would write in Elisp, to that set of programs that
>> Emacs' implementation of Elisp can deal with.

Karl> What Andy said.

>> There are many programs that you just can't write in Elisp, linguistic
>> expressiveness aside: the implementation just isn't fast enough. It
>> shouldn't be that hard to thread my inbox ;-)

Karl> What Andy said, again :-).

Do you know for certain that the performance problem is caused by the
elisp implementation, and not by some bad algorithm in whatever mail
program you are using?

My experience profiling Emacs is that the profiles have a long tail, and
the actual interpreter, while slow (it was #3 in the profiles as I
recall), would not result in an enormous gain even if it disappeared
completely.  I think this was also the result of the elisp JIT
experiment.

In the particular case I looked at, regular expressions were the #1 slow
point, followed by the GC; and even the GC was only 10%.  (My test was
heavy on regex use; though FWIW I suspect this is very common in elisp
code.)

I'm interested to understand how Guile will be faster-enough to make
this better.

I can see how this could be done via a very deep rewrite (e.g., if the
Emacs core was itself in lisp, you could do all the fun tricks that
typical CL implementations do), but I'm curious to know what other
clever approaches there are.

Tom