bug#69480: Emacs Lisp needs, for its great 'native-compile', 'declare' and 'the' for fixnums and arrays.

[Andrea Corallo]

Stephen Berman via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> On Thu, 29 Feb 2024 22:10:27 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Robert Boyer <robertstephenboyer@gmail.com>
>>> Date: Thu, 29 Feb 2024 13:40:14 -0600
>>>
>>> Consider this form:
>>>
>>> (progn (emacs-lisp-native-compile-and-load) (benchmark (build-sieve (expt 10
>>> 8)) 1))
>>>
>>> First of all, 'benchmark' has an obvious bug because it reports a time of
>>> .000005 seconds.
>>
>> You use benchmark incorrectly.  And you should use benchmark-run
>> instead, anyway.
>>
>>> After finding the file eratosthenese.el, the evaluation of the form above
>>> takes 69 seconds in Emacs.
>>>
>>> After entering SBCL and loading eratosthenese.lisp, (build-sieve (expt 10 
>>> 8))
>>> takes 8 seconds.
>>
>> It takes 16.7 sec on my system.
>
> I was curious to see how long it takes on my system, compared to the
> byte-compiled and uncompiled files, and the results surprised me.
> First, I visited the file eratosthenes.el, ran `eval-buffer' and then
> `M-: (benchmark-run nil (build-sieve (expt 10 8)))', with this result:
>
> (143.326808051 1 0.344846223)
>
> Then I ran `M-: (progn (emacs-lisp-native-compile-and-load)
> (benchmark-run nil (build-sieve (expt 10 8))))', with this result:
>
> (37.457440511 1 0.36922945500000004)
>
> The native compilation also produced a byte-compiled file
> eratosthenes.elc, so I then loaded that file and again ran `M-:
> (benchmark-run nil (build-sieve (expt 10 8)))', with this result:
>
> (21.854069551000002 1 0.3595161699999999)
>
> I was surprised that this was much faster than the run with native
> compilation, but I thought perhaps this was due to the time spent
> producing both the native and byte-compiled files (though more than 15
> seconds for that seemed unlikely), so I ran `M-: (progn
> (emacs-lisp-native-compile-and-load) (benchmark-run nil (build-sieve
> (expt 10 8))))' again, which just loaded the already native-compiled
> file (and updated its timestamp), but the result was practically the
> same as the first time:
>
> (37.095767574 1 0.36986937500000017)
>
> Why is the timing with native compilation so much slower than with byte
> compilation?

Because the file is not lexically scoped so we are not running
optimizations.

On my laptop I see:

11 secs byte compiled
18 secs native compiled

7 secs byte compiled with lexical scope
5 secs  native compiled with lexical scope.

Bests

  Andrea