Emacs has 40-45% CPU all the time

[renald]

Describe your issue

GNU Emacs 32.0.50 (build 1, aarch64-apple-darwin25.4.0, NS appkit-2685.50 Version 26.4.1 (Build 25E253)) of 2026-05-13

Doing no editing at all.

Profiler:

                                                               1374  61% - redisplay_internal (C function)
                                                                341  15%  - eval
                                                                271  12%   - doom-modeline-segment--buffer-info
                                                                270  11%    - doom-modeline-update-buffer-file-state-icon
                                                                265  11%       file-exists-p
                                                                  4   0%       verify-visited-file-modtime
                                                                  1   0%       file-remote-p
                                                                  1   0%      doom-modeline-spc-face
                                                                 46   2%   + doom-modeline-format--main
                                                                 18   0%   + doom-modeline-segment--modals
                                                                  2   0%   + doom-modeline-segment--buffer-position
                                                                  2   0%   + doom-modeline-segment--window-state
                                                                  1   0%   + doom-modeline-segment--matches
                                                                  1   0%   + doom-modeline-segment--workspace-name
                                                                  7   0%  + redisplay--pre-redisplay-functions
                                                                  1   0%  + mode-line-default-help-echo
                                                                859  38% - command-execute
                                                                853  37%  - byte-code
                                                                853  37%   - read-extended-command
                                                                853  37%    - read-extended-command-1
                                                                853  37%     - completing-read-default
                                                                853  37%      - apply
                                                                616  27%       - vertico--advice
                                                                616  27%        - apply
                                                                616  27%         - #<byte-code-function CB5>
                                                                616  27%          - apply
                                                                616  27%           - #<native-comp-function completing-read-default>
                                                                305  13%            + redisplay_internal (C function)
                                                                 13   0%            + vertico--exhibit
                                                                 11   0%            + timer-event-handler
                                                                  1   0%            + minibuffer-inactive-mode
                                                                237  10%       - consult--read
                                                                237  10%        - apply
                                                                237  10%         - consult--read-1
                                                                237  10%          - consult--with-async-f
                                                                237  10%           - #<byte-code-function 674>
                                                                237  10%            + consult--with-preview-f
                                                                  6   0%  + funcall-interactively
                                                                 13   0% + timer-event-handler
                                                                  5   0% + ...

What could be wrong?

Wkr,

Renald

Steps to reproduce

Open emacs. Start top.

System information

https://pastebin.com/vGJQXK9x

[hlissner]

Sounds like native compilation. Your Emacs is built with it. It runs in the background and natively-compiles Emacs Lisp files as they're loaded. It will stop once there are no uncompiled elisp files left. It will happen again anytime you update those packages (i.e. after a doom upgrade or doom sync -u) or up/downgrade Emacs.

You can turn off JIT compilation with:

;;; add to $DOOMDIR/init.el
(setq native-comp-jit-compilation nil)

Or you can adjust how many threads it may use (Doom defaults it to 1/4 of your CPU cores; on vanilla Emacs, the default is 1/2 your cores):

(setq native-comp-async-jobs-number 1)  ; only one thread

Side-note: on Emacs 31+, Doom turns off native-comp when your system is running on a battery (e.g. a laptop).

You may want to try either/both setting to see if your CPU issue goes away, to rule out other issues, but otherwise you should keep the feature on. It speeds up Emacs and happens less over time.

[panchoh]

Alternatively, you can append --aot to either doom upgrade or doom sync -u invocations to build the native code ahead of time. It takes a while, but at least you can do it when it is convenient for you (power-wise), and you reap the benefits of the improved general performance every time you run Doom Emacs.

[renald]

Thanks for the suggestions. I have tried all, both the `doom sync -u --aot` and the changes to config.el and init.el. Unfortunately, this does not change the CPU usage.

…

On 4 Jul 2026, at 18:58, pancho horrillo wrote: Alternatively, you can append `--aot` to either `doom upgrade` or `doom sync -u` invocations to build the native code *ahead of time*. It takes a while, but at least you can do it when it is convenient for you (power-wise), and you reap the benefits of the improved general performance every time you run Doom Emacs. -- Reply to this email directly or view it on GitHub: #120 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[hlissner]

Some more things to try:

• Add Emacs.app to Developer Tools in Settings -> Privacy & Security to exempt it from XProtect's runtime checks, which should mitigate the performance overhead starting child processes.
• Try the emacs-build cask instead of emacs-plus. One of:

  brew install --cask jimeh/emacs-builds/emacs-app  # latest stable release (30.2)
  # OR
  brew install --cask jimeh/emacs-builds/emacs-app-nightly  # 32.0.50

• I see you have exec-path-from-shell installed. This launches your interactive shell every time you start Emacs. If your shell dotfiles are doing anything expensive (like calling brew commands or initializing a very slow *env program, like rbenv or pyenv), then you're doing it every time you launch Emacs. (Frankly, I'd suggest just using doom sync --env instead of using exec-path-from-shell; it was created for that very purpose, and is a one-time cost).
• Make sure the Symbola font is installed. Emacs uses it as a fallback font to display glyphs your primary font can't display. If it's absent, Emacs can churn its GC trying to find a substitute.
• In the shell: defaults write org.gnu.Emacs NSAutoFillHeuristicControllerEnabled -bool false
• If you have any antivirus or MacOS has a runtime malware scanner other than XProtect (or you have any accessibility features that run as-you-type), see if you can add Emacs (and/or your $EMACSDIR and $DOOMDIR) to their whitelists in your system preferences.

[renald]

On 7 Jul 2026, at 12:32, Henrik Lissner wrote: Some more things to try: - Add Emacs.app to Developer Tools in Settings -> Privacy & Security to exempt it from XProtect's runtime checks, which should mitigate the performance overhead starting child processes.

On OSX I cannot find it.

- Try the emacs-build cask instead of emacs-plus. One of: ```sh brew install --cask jimeh/emacs-builds/emacs-app # latest stable release (30.2) # OR brew install --cask jimeh/emacs-builds/emacs-app-nightly # 32.0.50

Does not help out of the box. Run `doom sync -u --env -aot`, which rebuilt every package because the Emacs binary is now different after running the above. That also made no difference: still between 30-45% CPU time.

``` - I see you have `exec-path-from-shell` installed. This launches your interactive shell every time you start Emacs. If your shell dotfiles are doing anything expensive (like calling `brew` commands or initializing a very slow *env program, like rbenv or pyenv), then you're doing it every time you launch Emacs. (Frankly, I'd suggest just using `doom sync --env` instead of using `exec-path-from-shell`; it was created for that very purpose, and is a one-time cost).

Done. No difference.

- Make sure the Symbola font is installed. Emacs uses it as a fallback font to display glyphs your primary font can't display. If it's absent, Emacs can churn its GC trying to find a substitute. - In the shell: `defaults write org.gnu.Emacs NSAutoFillHeuristicControllerEnabled -bool false` - If you have any antivirus or MacOS has a runtime malware scanner (or you have any accessibility features that run as-you-type), see if you can add Emacs (and/or your `$EMACSDIR` and `$DOOMDIR`) to their whitelists in your system preferences.

Done. No difference. Profiling, most of the time seems to be the redisplay: 310 73% - byte-code 310 73% - read-extended-command 310 73% - read-extended-command-1 310 73% - completing-read-default 310 73% - apply 310 73% - vertico--advice 310 73% - apply 310 73% - #<byte-code-function 42A> 310 73% - apply 310 73% - #<native-comp-function completing-read-default> 145 34% - redisplay_internal (C function) 1 0% redisplay--pre-redisplay-functions 11 2% - vertico--exhibit 11 2% + vertico--protect 5 1% - timer-event-handler 5 1% + apply 1 0% + minibuffer--regexp-exit 55 12% - funcall-interactively Is there anything else I could do to debug?

…

-- Reply to this email directly or view it on GitHub: #120 (reply in thread) You are receiving this because you authored the thread. Message ID: ***@***.***>

[hlissner]

Sorry. I'm out of ideas. Unless you're on an 8K monitor, I can't imagine what else could cause this.

Profiling, most of the time seems to be the redisplay:

The profiler isn't helpful here. Whatever is causing it is likely not caused by Emacs itself. Likely a child process spawned at startup, which the profiler won't track.

[hlissner]

Is your config up somewhere I can see it?

[panchoh]

Maybe try again to locate the whitelisting for Emacs.app on XProtect.

Also, maybe install Emacs via nix, in order to rule out issues with the build you are using right now. (long shot)

[renald]

I've added you as a collaborator to https://github.com/renald/doom-emacs-d.

…

On 7 Jul 2026, at 14:56, Henrik Lissner wrote: Is your config up somewhere I can see it? -- Reply to this email directly or view it on GitHub: #120 (reply in thread) You are receiving this because you authored the thread. Message ID: ***@***.***>

[renald]

Done that now. Makes no difference. Interestingly, the CPU usage is only around 8% when on the doom 'home page'. Only when I select a recently viewed file, it moves the the 40-45% level. With kind regards, Renald

…

On 7 Jul 2026, at 14:59, pancho horrillo wrote: Maybe try again to locate the whitelisting for Emacs.app on XProtect. Also, maybe install Emacs via nix, in order to rule out issues with the build you are using right now. (long shot) -- Reply to this email directly or view it on GitHub: #120 (reply in thread) You are receiving this because you authored the thread. Message ID: ***@***.***>

[panchoh]

Question: does it ever stop using that much cpu, even if it takes hours?

(Another possible for cpu usage could be Emacs building trampolines, which is what is needed for advised functions that live on natively-built modules. It should eventually finish building them and stop the cpu hogging).

[renald]

All the time... Even after days.

…

On 7 Jul 2026, at 16:42, pancho horrillo wrote: Question: does it ever stop using that much cpu, even if it takes hours? (Another possible for cpu usage could be Emacs building trampolines, which is what is needed for advised functions that live on natively-built modules. It should eventually finish building them and stop the cpu hogging). -- Reply to this email directly or view it on GitHub: #120 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>