0

Emacs daemon greatly reduces time to load the first frame with emacsclient. However, when visiting a file with emacsclient, subsequent emacsclient frames load much faster than the first.

Command Load time (seconds)
Emacs daemon emacs --daemon 30
1. emacsclient frame - no file visited emacsclient -c <1
2. emacsclient frame visiting a file emacsclient -c "file1.org" 8
3. All subsequent emacsclient frames visiting the same file as in (2) with different filename emacsclient -c "file2.org" 1

What is slowing down the first emacsclient frame but not subsequent frames? Apparently that first call to emacsclient still loads something that is not being loaded in subsequent calls to emacsclient. Perhaps mode hooks? I can inspect load times for the daemon, which shows load time for individual packages. But I do not know how to inspect load times for each emacsclient frame.

If possible it would be great if the daemon could also take on the loading that seems to be executed during that first call to emacsclient.

Specs: GNU Emacs 27.1, use-package, Windows Subsystem for Linux, X410 window manager.

Additional information: Test times above are for org files (with org packages successfully loaded by the daemon.) Similar differential load times observed for identical text files. The observed behavior is independent of the file order, that is, the first invocation is slow and the subsequent invocations fast regardless of whether opening filename1 then filename2 or vice versa. Overall slowness may be caused by the fact I am running a virtual machine (WSL)

Update Following phils suggestion, I compared the value of the features variable after each invocation of emacsclient.

After running emacs --daemon, invoking emacsclient -c without visiting a file loads an empty frame in less than one second. The value the features variable is quite large, so I defer quoting the full value in this thread. Next, invoking emacsclient -c "file1.org" loads the frame in 8 seconds. The difference between the value of features between the first invocation without visiting a file and the invocation visiting a file is:

rx org-eldoc face-remap flyspell ispell org-indent ol-eww eww mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnir gnus-sum shr svg dom gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader ol-docview doc-view jka-compr image-mode exif ol-bbdb ol-w3m pp cl-print

The third invocation, emacsclient - c "file2.org" loads the frame in less than one second and the value of features is unchanged from the second invocation.

Based on the change in the value of the features variable, there appear to be several suspects for the one-time, eight second delay experienced when first visiting a file. The only one I recognize is flyspell, which is configured by use-package to load with hooks to text-mode and org-mode. Is there a way to load these features in the daemon rather than when opening files? The fact that subsequent invocations of emacsclient do not cause this delay suggests they need be loaded only once.

10
  • Those times seem very slow regardless of any actual issues; however... you're complicating things by visiting a file with your first client. Are the timings different if you repeatedly use emacsclient -c rather than emacsclient -c "filename"? If the slowness is not "the first time I start a client" but rather "the first time I visit a file of a given type" then it will just be the time taken to load whichever libraries are relevant to that type of file. (Are "filename1" and "filename2" the same type of file?)
    – phils
    Jun 29 at 11:55
  • A related test: emacs --daemon "filename1" followed by emacsclient -c "filename2"
    – phils
    Jun 29 at 11:59
  • Re-reading, you're saying this is for org files, and org-mode is a huge set of libraries for which loading takes a noticeable amount of time even on my fast machine, so I suspect the situation is exactly as I've suggested above. Simply (require 'org) in your init file if you want to automatically load it when Emacs starts.
    – phils
    Jun 29 at 12:02
  • I've converted this to an answer, as I think it's very likely to be correct.
    – phils
    Jun 29 at 13:03
  • @phils org packages are successfully loaded by the daemon: Loading package org... Configuring package org... Configuring package org...done Loading package org...done (1.840s), so I don't think this is the cause of the differential delay observed between opening these identical files in arbitrary order using emacsclient. Though it could be some other package or process that is not being loaded by the daemon and is deferred to the first but not subsequent invocations of emacsclient.
    – Snelephant
    Jun 29 at 13:15
3

emacsclient -c "filename1" [...] for org files [...] What is slowing down the first emacsclient frame but not subsequent frames?

The fact that you are visiting an org-mode file for the first time when you open that frame, which means that Emacs must load the org libraries (which are numerous and large).

If possible it would be great if the daemon could also take on the loading that seems to be executed during that first call to emacsclient.

Simply put this in your init file:

(require 'org)

Depending on config (e.g. mode hooks, as you mentioned), there might be additional things being loaded once you actually trigger the major mode for the first time, so you might want to require anything additional.

The features variable will show you all the things which are currently loaded, and after-load-functions can be used to log which files are being loaded, but you might just try something like this as a shortcut:

(defun my-load-org-mode-more () (with-temp-buffer (org-mode)))
(add-hook 'emacs-startup-hook #'my-load-org-mode-more)
2
  • Calling (with-temp-buffer (org-mode)) in the emacs daemon solved the delay. The first invocation of emacsclient -c "file-to-visit.org" now opens in less than one second. Presumably this trick can help for delays caused by modes other than org-mode.
    – Snelephant
    Jun 30 at 21:36
  • Yes, you should be able to do that with any major mode for which an empty buffer is a valid state (which should cover any modes intended for editing files).
    – phils
    Jun 30 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.