bug#59692: 29.0.60; Reduce installation size by disabling byte-compilation for some lisp files that won't benefit

[daanturo]

> measurements of code speed with and without byte-compilation

I tried to evaluate performance different:

### Load time

Helper macro:
```emacs-lisp
(defmacro my-with-deferred-gc (&rest body)
  `(dlet ((gc-cons-threshold most-positive-fixnum) (gc-cons-percentage 0.75))
     ,@body))
```

(Each of those measures was executed in a new Emacs instance, as the
second `load` is (for me) cheaper than the first `load`).

#### lisp/leim/ja-dic

(my-with-deferred-gc (benchmark-progn (load
"/usr/share/emacs/29.0.60/lisp/leim/ja-dic/ja-dic")))

> .el:
Loading /usr/share/emacs/29.0.60/lisp/leim/ja-dic/ja-dic.el (source)...done
Elapsed time: 0.707891s
> .elc:
Loading /usr/share/emacs/29.0.60/lisp/leim/ja-dic/ja-dic...done
Elapsed time: 0.104832s
> .eln:
Loading /usr/share/emacs/29.0.60/lisp/leim/ja-dic/ja-dic (native compiled 
elisp)...done
Elapsed time: 0.104676s


#### Other auto-generated lisp files in lisp/leim/quail, all of them are
Chinese at the moment, the largests being ZIRANMA.el, ARRAY30.el:



(my-with-deferred-gc (benchmark-progn (load
"/usr/share/emacs/29.0.60/lisp/leim/quail/ZIRANMA")))

> .el:
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/ZIRANMA.el (source)...done
Elapsed time: 0.037230s
> .elc:
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/ZIRANMA...done
Elapsed time: 0.058042s
> .eln:
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/ZIRANMA (native compiled 
elisp)...
Elapsed time: 0.062904s

(my-with-deferred-gc (benchmark-progn (load
"/usr/share/emacs/29.0.60/lisp/leim/quail/ARRAY30")))

> .el
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/ARRAY30.el (source)...done
Elapsed time: 0.031518s
> .elc
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/ARRAY30...done
Elapsed time: 0.037412s
> .eln
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/ARRAY30 (native compiled 
elisp)...done
Elapsed time: 0.041110s


(my-with-deferred-gc (benchmark-progn (load
"/usr/share/emacs/29.0.60/lisp/leim/quail/QJ")))
> .el
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/QJ.el (source)...done
Elapsed time: 0.001649s
> .elc
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/QJ...done
Elapsed time: 0.004481s
> .eln
Loading /usr/share/emacs/29.0.60/lisp/leim/quail/QJ (native compiled 
elisp)...done
Elapsed time: 0.005001s



For "ja-dic.el", byte-compilation clearly helped speedup loading. But
native-compilation doesn't offer any more significantly. As I inspect
"ja-dic.elc", byte-compilation did by expanding macros to
`(defconst var literal-list)` forms, I think that native compilation
won't offer more about run time performance.


For auto-generated files under lisp/leim/quail (ZIRANMA, ARRAY30, QJ
tested above), sometimes compilation even slows down the loading process
compared to just interpretation.


About the run time performance, since I don't know Chinese, I will
approximately benchmark lisp/leim/quail/vnvni.el (Vietnamese) instead as
this file is quite similar to ZIRANMA.el: both has only 2 forms --
(quail-define-package ...) and (quail-define-rules ...).

ydotool is used (https://github.com/ReimuNotMoe/ydotool) to perform
auto-typing as in bench-quail.el attached. The function to be
benchmarked is #'quail-input-method.

emacs -q -l bench-quail.el --eval "(progn (my-to-new-buffer) 
(my-benchmark-quail nil))"
emacs -q -l bench-quail.el --eval "(progn (my-to-new-buffer) 
(my-benchmark-quail 'compiled))"


Benchmarking results: (note that :num means the total key pressed by ydotool).

Loading /usr/share/emacs/29.0.60/lisp/leim/quail/vnvni.el (source)...done
Elapsed time: 0.016844s (0.008795s in 1 GCs)
(:compiled nil (:num 145 :total-time 2.118776153 :average 0.014612249331034484))


Loading /usr/share/emacs/29.0.60/lisp/leim/quail/vnvni (native compiled 
elisp)...done
Elapsed time: 0.034253s (0.009630s in 1 GCs)
(:compiled compiled (:num 145 :total-time 2.117245182999999 :average 
0.014601690917241374))



So I conclude that those quail lisp package files' compilation statuses,
whether compiled or not, doesn't affect run-time performance at all.

### lisp/international/titdic-cnv.el's pinyin-convert

It produce a single form: (defconst var literal-list) so the
corresponding produced ".elc" file is just the same with new lines
joined. Also the times taken to load lisp/language/pinyin.elc and
/lisp/language/pinyin.el aren't different anyway.

### About the patch

In the patch below, I disabled native-compile for "ja-dic" while keeping
byte-compile (by modifying `generate-lisp-file-trailer` keyword args),
and disable compilation altogether for files produced by titdic-convert,
miscdic-convert, pinyin-convert. There's no new .dir-locals files
introduced like the previous patch.

> Disk space is cheap these days.

But it's always better to be light if we don't suffer any penalties. A
little number of megabytes saved will always be appreciated by people
with metered connection and/or limited bandwidth, or people who have
multiple versions of Emacs installed. Disk space is indeed becoming
cheaper, but with varying pace among countries. I am currently using a
laptop which only has 238GiB & un-expandable, that explains my joy when
pacman shows net upgrade size being negative during system updates.

Thanks to the patch, I saved 20.20 MiB by a couple of flag flips without
making any new files. Please consider again if you think it makes more
sense than my previous justifications, thank you.

-- 
Daanturo.

bench-quail.el
Description: Text Data

0001-Inhibit-compilation-for-some-quail-packages-generators.patch
Description: Text Data