Re: C and Emacs Lisp code parts

[Karl Fogel <kfogel@red-bean.com>]

Andy Moreton <andrewjmoreton@gmail.com> writes:
>> On 01.07.2016 11:25, Eli Zaretskii wrote:
>>>
>>> So yes, we need numbers to make rational decisions about this.
>>
>> Sorry, but that's irrational. Compare doesn't need numbers. To compare
>> implementations in C an exec is needed - which doesn't exist yet. If written,
>> the reason basically is gone, because C will be faster - unless something went
>> wrong, which is a case for debugging rather than benchmarks.
>
>Eli is right. You believe that C is always faster, but most programmers'
>intuitions about performance are wrong.  Benchmarks and numbers give a
>more objective basis for making rational design decisions.

Yes, Eli is exactly right, and is being completely rational.

Andreas, for example:

Suppose 100 functions have been converted from C to Lisp.  Of those 100, say that 3 are responsible for 95% of the slowdown that resulted (resulted from the conversion of the group of 100, that is).  Meanwhile, the other 97 are only rarely called, or are never called in loops, whatever -- in other words, they are not responsible for much slowdown.

If you convert all 100 functions back to C, then you lose the maintainability advantages of having the innocent 97 in Lisp, for very little real gain; you could have gotten almost all the gain from just identifying the 3 important functions and converting only them.

That's why Eli's point about profiling first, and basing any decisions on the results, is so important.

The adage "C is faster" is not always correct in any case, as others here have pointed out.  But what I'm saying above is that, even if it *were* always true, it would still not be an argument for converting lots of functions back to C, or for avoiding converting more functions from C to Lisp.  You have to know *which* ones need to be in C.  Manual testing can maybe identify a few of those, and if you can perform such tests and identify some such functions, that would be great.  An even more general way to do it (with correspondingly greater up-front investment, of course) is a performance test suite.

But to just recommend that Emacs stop moving things from C to Lisp, or move things back to C, without knowing *which* things and why, is to make a recommendation too vague to guide anyone's actions.

Best regards,
-Karl