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

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

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?

Steve Berman