sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
I don't want to be splitting hairs too much, but most of the
slowness I see *is* related to Elisp. Redisplay is plenty fast for
me, and buffer operations as well. Stuff like func-menu, on the
other hand, is causing noticeable delays as well as things like
jumping to a non-displayed group in Gnus (... and quite a few other
things in Gnus.)
Displaying groups in Gnus is provably connected to the slowness of
our text-properties implementation. Where we simulate text properties
using extents, FSF Emacs uses balanced trees, offering an
order-of-magnitude better performance.
As for redisplay, I cannot fathom how it can be plenty fast for anyone
who tries to display anything other than plain text.
No doubt improvements are possible in areas other than Elisp.
However, Elisp *is* a main source of slowness.
I disagree, at least in the case of applications I am encountering.
Hrvoje> One area where using a new lisp engine would be a huge
win
Hrvoje> is the speed of function calls, which are currently
Hrvoje> notoriously slow.
Right. In most modern Scheme engines, function calls are pretty
close to free, especially when they're tail calls.
I think that the new direction of XEmacs will likely cause another
split. I would prefer a loosely Common Lisp-based XEmacs, perhaps
built on top of clisp. We are bound to disagree here.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Be nice to your kids.
They'll choose your nursing home.