GNU bug report logs -
#69480
Emacs Lisp needs, for its great 'native-compile', 'declare' and 'the' for fixnums and arrays.
Previous Next
Full log
Message #23 received at 69480 <at> debbugs.gnu.org (full text, mbox):
On Thu, 29 Feb 2024 22:10:27 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Robert Boyer <robertstephenboyer <at> 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
This bug report was last modified 164 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.