bug#58634: Long delay with blank screen whilst loading desktop at emacs startup

[Alan Mackenzie <acm@muc.de>]

Hello, Eli and Andrea.

On Wed, Oct 19, 2022 at 19:11:38 +0000, Andrea Corallo wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> Date: Wed, 19 Oct 2022 13:28:42 +0000
> >> From: Alan Mackenzie <acm@muc.de>

> >> In my current desktop file, I have 166 buffers.  I'm using an up to date
> >> Emacs 29.

> >> On loading this desktop into emacs -nw on X Windows, or into a linux
> >> console, it takes a long time to load, around 28 seconds.  Of that time,
> >> my terminal window/screen is entirely blank for around 18 seconds, with
> >> not even a mode line being displayed.

> > And nothing in the echo-area, either?

Nothing in the echo-area, no.

> >> Doing the same in a GUI run on X also takes around 28 seconds to load,
> >> but during that time, random buffers are displayed on the screen,
> >> complete with mode line.

> >> I think the native compiler is running in the background during this 28
> >> seconds, and thus contributes to the relatively long start up time.

> > To test this hypothesis, leave Emacs alone running until
> > list-processes shows an empty list, then restart Emacs.  This time,
> > you should not see the delay due to native compilation, so if there
> > still is a delay, it is unlikely to be due to native compilation.

I did this, and there was still a delay.  So I'm pretty sure it's nothing
to do with native compilation, now.

> > In any case, you should be able to see whether it's native compilation
> > by watching the emacs --batch processes that run on your system during
> > that time.

> Yes totally agree, listing processes is the quickest way to confirm this
> hypothesis.

> Alan please let us know.

It's nothing to do with native compilation.  Apologies.

What I did do was insert debugging code which prints an extra . for each
loaded file.  More precisely:

diff --git a/lisp/desktop.el b/lisp/desktop.el
index ef73bc596d..554e82ab40 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -1599,6 +1607,10 @@ desktop-create-buffer
            (setq desktop-buffer-ok-count (1+ desktop-buffer-ok-count))
          (setq desktop-buffer-fail-count (1+ desktop-buffer-fail-count))
          (setq result nil))
+        (let ((buffer-total-count (+ desktop-buffer-ok-count
+                                     desktop-buffer-fail-count)))
+          (message (concat "Restoring desktop..."
+                           (make-string buffer-total-count ?.))))
        ;; Restore buffer list order with new buffer at end. Don't change
        ;; the order for old desktop files (old desktop module behavior).
        (unless (< desktop-file-version 206)

On my linux console, this displays a few buffers (out of ~166) in
addition to the dots in the echo area.

I have a theory.  The function desktop-restore-file-buffer visits a file
with find-file-noselect, then calls switch-to-buffer on it.  (This is the
interactive command on C-x b.)  In earlier times, there would be a delay
in visiting the next file, and in this delay redisplay would happen.  The
user would thus see a sequence of short displays of his files being
loaded.  Nowadays, the time to visit a file is so short that redisplay
never registers a delay, and so doesn't redisplay.  But with something
slowing the processing down a little (outputting "Restoring
desktop......", for example), the OS's file system goes to sleep, and
takes long enough to wake up for redisplay to trigger.  Or something like
that.

What do you think?

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).