Re: C and Emacs Lisp code parts

[Karl Fogel]

Andy Moreton <address@hidden> 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