Why is emacs slow to give the prompt

Question

If I remove my .emacs file and .emacs.d folder, just to be sure that what I observe is not caused by an issue in my personal configuration, and I invoke emacs foo.txt the emacs windows opens, stays blank for at least 5 seconds with 'Lisp Interaction ElDoc' written in the center of the bar at bottom where the major mode is usually indicated. Then (that is after several seconds), the window gets separated vertically into two parts with the splash screen on the bottom part and the document foo.txt on the top part, and the 'Lisp Interaction ElDoc' gets replaced by '(Text)' as expected.

If I subsequently close the document and immediately invoke emacs foo.txt again, then I directly get the final window (separated in two, with the splash screen and everything) without being stuck in the first state for seconds.

But, if I close the document and wait for some amount of time (a minute or so), and then invoke emacs foo.txt again, the emacs window opens, it stays blank for at least 5 seconds with '(Fundamental)' written in the center of the bar at bottom, and the message 'Loading /usr/share/emacs/site-lisp/site-start.d/rpmdev-init.el... done' (which is the last file loaded from /usr/share/emacs/site-lisp/site-start.d/ if you wonder). Then, the file pops up, together with the splash screen, etc.

The content of *Messages* gives me no information whatsoever on what emacs can be trying to do between finishing loading rpmdev-init.el and displaying the splash screen (with the message "For information about GNU Emacs and the GNU system, type C-h C-a."). Here is the content of *Messages*:

Loading /usr/share/emacs/site-lisp/site-start.d/auctex.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/autoconf-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/clang-format.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/clang-include-fixer.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/clang-rename.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/cmake-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/desktop-entry-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/mercurial-site-start.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/pg-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/preview-latex.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/protobuf-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/rpmdev-init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

This behavior (having sometimes to wait for seconds before being able to edit the file) is annoying. I know that I could start emacs as a server to avoid reloading everything everytime I want to open an emacs window, but nevertheless, I would like to understand what is happening behind the scene, because this seems to be the trace of something anormal. So my question is: does anyone has an idea of what causes emacs to have this behavior? Or any clue on how to proceed to figure it out?

I tried with emacs -q and emacs -Q and observe the same phenomenon. I am using emacs 27.2 on Fedora 34.

Edit: similar questions have very often been posted on StackOverflow (and much more on SO than on any other StackExchange website, as far as I can tell). For instance:

• The closest question I found to my issue is here.
• Another very close one is here (or here which is merely a duplicate).
• That one.
• That one and that one seemed to be irrelevant to my case.
• etc.

The usual suspects are a bad configuration (excluded here because the issue happens even with -Q) or a bad hostname configuration (should be fixed on modern versions of emacs as far as I understood, and, anyway, my hostname is correctly configured).

I am still trying to compare the traces emacs_slow.strace and emacs_fast.strace obtained as the result of

strace -tt -o emacs_slow.strace emacs foo.txt -eval '(kill-emacs)' && \ 
strace -tt -o emacs_fast.strace emacs foo.txt -eval '(kill-emacs)'

They are both about 21k lines and fairly similar. If someone has a clue on what to check specifically for, advice are welcome.

Answer 1

I finally found the cause of the issue. It turns out to be rather specific to my personal case, but I post an answer here rather than deleting the question because:

1. It turns out that my problem really is different from all other similar issues signaled on StackOverflow and listed in my post.
2. The way I managed to diagnose the problem can be useful to others (it was indeed proposed as part of a solution and also as a comment on two of the above-listed questions).
3. Even though it is rather specific, I am not the first one to encounter it, as I finally found someone with the same issue (though they did not identify it by the same symptoms) and I successfully applied their fix.

I really got to understand what was happening thanks to strace. The trace obtained when emacs was slow to load was really similar to the one when it was fast to load, except that at this call

faccessat2(AT_FDCWD, "/run/netsop/u/_MTN/format", F_OK, AT_EACCESS) = -1 ENOENT (No such file or directory)

the slow run was waiting 8 seconds before continuing, while the fast run was continuing immediately.

/run/netsop/u/ is a network mount point, whose sub-folders turn out to be automatically mounted on demand (and automatically unmounted after some time), so what happens became clear: emacs was trying to see if the file /run/netsop/u/_MTN/format was present or not, and just to get this answer, it triggered mounting of the folder (which happens to take more or less 8 seconds). When emacs was launched again while the mount point was still up, it was getting its answer instantaneously.

Once I knew that the cause of the problem was emacs trying to see whether _MTN/format exists, I googled for it and found the fix mentioned above, which is simply to add

(setq vc-handled-backends nil)

in .emacs, in order to disable the version control abilities of emacs.

Of course, a better fix would be to keep the vc-handled-backends and, e.g., specify to emacs a list of folders where it should not look for version control configuration files, but I am not aware of such a solution.

Answer 2

Is it this?

*** GNU/Linux: slow startup on Linux-based GNU systems.

People using systems based on the Linux kernel sometimes report that
startup takes 10 to 15 seconds longer than 'usual'.

This is because Emacs looks up the host name when it starts.
Normally, this takes negligible time; the extra delay is due to
improper system configuration.  This problem can occur for both
networked and non-networked machines.

Here is how to fix the configuration.  It requires being root.

**** Networked Case.

First, make sure the files '/etc/hosts' and '/etc/host.conf' both
exist.  The first line in the '/etc/hosts' file should look like this
(replace HOSTNAME with your host name):

    127.0.0.1      HOSTNAME

Also make sure that the '/etc/host.conf' files contains the following
lines:

    order hosts, bind
    multi on

Any changes, permanent and temporary, to the host name should be
indicated in the '/etc/hosts' file, since it acts a limited local
database of addresses and names (e.g., some SLIP connections
dynamically allocate ip addresses).

**** Non-Networked Case.

The solution described in the networked case applies here as well.
However, if you never intend to network your machine, you can use a
simpler solution: create an empty '/etc/host.conf' file.  The command
'touch /etc/host.conf' suffices to create the file.  The '/etc/hosts'
file is not necessary with this approach.

Quoted from the PROBLEMS file; type C-hC-p