Bug#1050577: emacs: please limit number of native-compilation workers
Sean Whitton writes: > I would be in favour of patching in setting it to 1. It's not a problem > for people to increase it, after all. No objection, fwiw. I could also see adding some DEBIAN_EMACS_DEFAULT_COMPILE_CONCURRENCY variable, or somehthing, if that would be helpful. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1050577: emacs: please limit number of native-compilation workers
Hello, On Sat 26 Aug 2023 at 11:29am -03, David Bremner wrote: > 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. I would be in favour of patching in setting it to 1. It's not a problem for people to increase it, after all. -- Sean Whitton signature.asc Description: PGP signature
Bug#1050577: emacs: please limit number of native-compilation workers
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
