Package: emacs
Version: 1:29.1+1-2
Severity: wishlist
native-comp-async-jobs-number is a variable defined in ‘comp.el’.
Its value is 0
Default number of subprocesses used for async native compilation.
Value of zero means to use half the number of the CPU’s execution units,
or one if there’s just one execution unit.
I think the upstream default is too aggressive, and we should set it
to a smaller number to reduce the "fork bomb" like behaviour of
spawning NUM_PHYSICAL_CORES worker processes for each user created
emacs process. This particularly manifests itself if the user is
running more than one emacs process. As an example, prior to patching
the notmuch test suite, I got 200 native compilation processes on my
desktop.
Upstream may be correct that "one emacs process per machine" is the
most common scenario, but the bad outcome of having the limit too
small seems better than the bad outcome of having it too high. People
do use emacs in lots of other scenarios (e.g. servers and automated
processes), and expecting them all to customize their emacs to avoid a
performance / UX regression seems unkind. AFAICT since the native
compilation is asynchronous, there is no obvious pause by queuing the
compilation jobs.
-- System Information: Debian Release: trixie/sid APT prefers testing
APT policy: (500, 'testing') Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages emacs depends on:
ii emacs-gtk 1:29.1+1-2
emacs recommends no packages.
emacs suggests no packages.
-- no debconf information
