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
