Re: C and Emacs Lisp code parts

[Alan Mackenzie]

Hello, Andreas.

On Fri, Jul 01, 2016 at 10:39:26AM +0200, Andreas Röhler wrote:


> On 01.07.2016 10:13, Eli Zaretskii wrote:
> >> From: Andreas Röhler <address@hidden>
> >> Date: Fri, 1 Jul 2016 10:03:07 +0200

> >> last years parts of C code have been switched into the Lisp area. There
> >> are pro and cons, the cons .....

I think you meant "pros" here.

> >> ..... seems to be an easier maintenance, to protect against the
> >> lack of skilled C-developers.

Of course, that fails to protect against any lack of skilled Emacs Lisp
developers.  Which is more likely?

> >> The backside is a general slowness, not felt in details of such a
> >> change, but cumulated.Would liketo see this strategy changed.r

Can you quantify this alleged general slowness?  It could well be (and I
suspect it is) that the rewriting of certain parts of Emacs in Lisp have
had a negligible, unmeasureable impact on Emacs's speed.

Can you be more specific, and identify some of these C -> Lisp changes
which you suspect have slowed Emacs?  To be honest, I'm not aware of any
of these changes at all, with just a vague background awareness they may
have taken place.

> >> Rather focus at a fast and small core. Reduce the rate of changes
> >> maybe. My preferred Emacs must not provide everything, but be quick
> >> and reliable and easy to extend.

I think it is all these things, though there is room for improvement
(which is steadily happening).

> >> Emacs Lisp seen as designed for the user-space.

> > To compare performance, we need a performance test suite.  Without
> > measuring the impact of these changes, we cannot rationally discuss
> > the alleged slowdown.

> You need a number to believe function running from Emacs Lisp is slower 
> than an implementation in C?

You need numbers to show that any such difference is important enough to
suffer the disadvantages of C over Lisp for (slower, more difficult,
maintenance, mainly).

-- 
Alan Mackenzie (Nuremberg, Germany).