Very long startup time with no obvious cause

Recently my Emacs has been taking a very long time to start up — often around 8–10 s, and sometimes more. If I close Emacs and then start it up again, the startup time usually decreases to around 5 s, but then it increases back to 8–10 s after I put my computer to sleep. The really curious thing about this is that whenever I try to run `esup` or a similar profiler, the problem goes away entirely: Emacs starts near-instantly, and the profiler consistently reports around 3.5 s startup time (all of which is straightforwardly due to my `init.el`). I can find nothing else obvious which might be causing this delay — and, before you ask, I can’t quite remember when the problem started. Does anyone have any other ideas whatsoever as to what might be causing this or how I might be able to fix it? (For reference, my .emacs.d is at [https://github.com/bradrn/.emacs.d/blob/bef9de6ad27e214fa5972ed220d839721d8febca/init.el](https://github.com/bradrn/.emacs.d/blob/bef9de6ad27e214fa5972ed220d839721d8febca/init.el); I am using Emacs 28.1 on Windows 10, without native compilation.)

You could always try manually profiling by adding a bunch of timestamped message statements in between the uses of use-package. The \*messages\* buffer should then give you a pretty clear indication of where that time is spent.

I’ve tried that too. If I recall correctly, it was consistent with observations from `esup` etc.: whatever might be causing this delay, it’s not in `init.el`.

Does it make any difference if you start with the `--no-site-file` option?

Alas, it doesn’t appear to change anything…

I would try some things: 1. use-package-verbose 't will print out especially long init or config times 2. use-package :disable t on suspected packages until you find the culprit. 3. Check out an older version of your emacs.d repo where the problem doesn't happen, and then use git bisect to find the change that causes it. Actually you may want try this first, I just thought of it, and am too lazy to move it up :-)

:-( Off the top of my head, it sounds like it might be a caching issue - that resuming after sleep causes a cache regen that is then used on subsequent starts.

Trying `(setq use-package-verbose t)` doesn’t reveal anything particularly useful — not especially surprising, since I’ve already established the issue isn’t in my `init.el`. I’ll try `:disable`ing stuff next. (Unfortunately, I doubt that `git bisect` will reveal anything helpful: I have a horrible habit of forgetting to commit changes in my `init.el`, then committing several changes at once later… besides, I committed a big refactor of my `init.el` a whole ago, and if that’s the culprit then `git bisect` won’t help at all.)

Oh, quite probably, but how to find the troublesome cache? That’s the difficult bit…

Yes indeed; have you already looked at what's creating/using caches in your Emacs config directory? E.g. in my `~/.config/emacs/`, there's `eln-cache/`, `jabber-avatar-cache/` and `projectile.cache`. i don't use Windows so don't know the exact command, but you could also do a search for files in that directory that have modified since the machine came back from sleep.

You could try using 'Process Monitor' to see if Emacs is spending time trying to access too many resources e.g recursing through too many files/directories. Also on Windows Emacs performance can be greatly impacted by active monitoring anti-virus.

I've seen hangs with filesystem stuff, e.g. disconnected sshfs fuse fs. Something might be waiting for timeout somewhere

`use-package` has some keywords which help you to avoid requiring the whole file, like `:commands`, `:bind`, `:custom`, `:mode`, `:hook` etc, so consider rewrite your config using them (when possible)

> Trying (setq use-package-verbose t) doesn’t reveal anything particularly useful there's also `use-package-minimum-reported-time` tuning

what about `emacs -Q` ?

That works — `emacs -Q` starts almost instantly, as does `emacs -q`.

Can you not use emacs server & emacsclient on Windows?

Yes,even 3.5 seconds is too long for emacs startup You'd better use/study some mature 3rd distribution (doomemacs?) instead of creating your own configuration from the scratch. As I can see, you lacks knowledge to optimize. Example 1, in your `emacs-lisp-mode-hook` and `lisp-mode-hook`, maybe you could idle load the `lispy-mode` to speed your startup. Suppose the first buffer in Emacs is `*scratch*` buffer. Example 2, turning off `tool-bar-mode`, In my setup, https://github.com/redguardtoo/emacs.d/blob/f90134620aa87cd465df667148fea04e0ca23f8d/lisp/init-essential.el#L195 , I turn off the toolbar in idle loader to speed up start up, ``` (defun my-mini-ui () "Minimum ui." ;; NO tool bar, scroll-bar (when window-system (scroll-bar-mode -1) (tool-bar-mode -1) (horizontal-scroll-bar-mode -1))) (my-run-with-idle-timer 2 #'my-mini-ui) ``` In your setup, you just turn off the tool-bar-mode directly. It's a bit slower, ``` (menu-bar-mode -1) (tool-bar-mode -1) (scroll-bar-mode -1) ``` Example 3, you don't use `early-init.el` to speed up startup, See how I use it (https://github.com/redguardtoo/emacs.d/blob/master/early-init.el)

Yeah, this. This will tell you where the hangup is.

Run daemon mode?

I did use it at one point, but I find I regularly end up restarting Emacs in any case (e.g. every time I shut down my laptop, which is often). (ping /u/skinney6, who just asked the same question)

> Yes,even 3.5 seconds is too long for emacs startup To be fair, a good portion of that time comes from `(package-initialize)`. Alas, it seems that things are generally slower on Windows… > You'd better use/study some mature 3rd distribution (doomemacs?) instead of creating your own configuration from the scratch. I used spacemacs at one point, but eventually decided that I prefer to write my own config myself. > As I can see, you lacks knowledge to optimize. I’m always willing to learn, though! > Example 1, in your `emacs-lisp-mode-hook` and `lisp-mode-hook`, maybe you could idle load the lispy-mode to speed your startup. Suppose the first buffer in Emacs is `*scratch*` buffer. Excellent point! I’ll try it and see if that helps. > Example 2, turning off `tool-bar-mode` … IIRC this didn’t have a significant performance penalty in my case, though I’ll certainly try this approach too. > Example 3, you don't use `early-init.el` to speed up startup At one point I did try setting `package-enable-at-startup` to `nil`, but that just broke everything. If nothing else works I’ll look into `early-init.el` again.

Check for package quick start, it solves the problem of `(package-initialize) `

I’ve already enabled it ([L18](https://github.com/bradrn/.emacs.d/blob/bef9de6ad27e214fa5972ed220d839721d8febca/init.el#L18)).

The package [benchmark-init](https://melpa.org/#/benchmark-init) may be useful for that.

Since you have your `init.el` under version control, you could try bisecting ([git-bisect](https://git-scm.com/docs/git-bisect)) and running a profiler like [hyperfine](https://github.com/sharkdp/hyperfine) to search for this regression.

>Actually you may want try this first, I just thought of it, and am too lazy to move it up :-) Only because M-<Up> doesn't work in reddit.

Then you can remove the `(package-initialize)`. Make sure that you're using a later version than `27.1`

I did actually remove the `(package-initialize)`, though I haven’t gotten around to committing that change yet. Currently I’m doing: (unless (and (boundp 'package--initialized) package--initialized) (package-initialize)) Which hopefully should account for all cases.

I tried deleting everything which looked even vaguely cache-like. Unfortunately, it doesn’t seem to have changed anything.

Well dang. :-( i'm not necessarily suggesting you *move* to a daemon-based setup, unless that actively works for you, but i'm interested to know whether there's any significant difference if you start Emacs as a daemon?

You should probably remove that as well. Once you have enabled package quick start, the `(package-initialize)` should not be run at all as all of its autoload should be inside `package-quickstart.el` already. So, the `package--initialized` should be `nil` for a normal start case.