Re: Where do you want to go tomorrow?
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
writes:
> The immediate consequence of a new engine is going to be
> performance; XEmacs runs dog-slow in many areas, and (long-term, not
> ignoring the recent improvements) it has become slower faster than
> machines have been getting faster.
Hrvoje> Michael, if you take a look at XEmacs' speed in "real-life"
Hrvoje> applications (define them as you deem appropriate), you'll see that
Hrvoje> much of the slowness doesn't lie in elisp. For instance, we have slow
Hrvoje> buffer filling (up to 10 times more slower than FSFmacs), and very
Hrvoje> slow redisplay. Only this is enough to slow things down considerably.
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.) No doubt improvements are possible in areas other than Elisp.
However, Elisp *is* a main source of slowness.
Hrvoje> One area where using a new lisp engine would be a huge win is the
Hrvoje> speed of function calls, which are currently notoriously slow.
Right. In most modern Scheme engines, function calls are pretty close
to free, especially when they're tail calls.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla