From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#58634: Long delay with blank screen whilst loading desktop at emacs startup Date: Wed, 19 Oct 2022 19:58:36 +0000 Message-ID: References: <83edv3zud8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16140"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 58634@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 19 21:59:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1olFDd-0003xq-Cj for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Oct 2022 21:59:13 +0200 Original-Received: from localhost ([::1]:59202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olFDc-0004ye-0S for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Oct 2022 15:59:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1olFDS-0004yO-Fp for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2022 15:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:32887) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1olFDS-0006z3-8Q for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2022 15:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1olFDS-0003U0-3P for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2022 15:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2022 19:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58634 X-GNU-PR-Package: emacs Original-Received: via spool by 58634-submit@debbugs.gnu.org id=B58634.166620952613367 (code B ref 58634); Wed, 19 Oct 2022 19:59:02 +0000 Original-Received: (at 58634) by debbugs.gnu.org; 19 Oct 2022 19:58:46 +0000 Original-Received: from localhost ([127.0.0.1]:60198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1olFDC-0003TX-0V for submit@debbugs.gnu.org; Wed, 19 Oct 2022 15:58:46 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:58608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1olFD9-0003TI-5B for 58634@debbugs.gnu.org; Wed, 19 Oct 2022 15:58:44 -0400 Original-Received: (qmail 29082 invoked by uid 3782); 19 Oct 2022 21:58:37 +0200 Original-Received: from acm.muc.de (p4fe15a32.dip0.t-ipconnect.de [79.225.90.50]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 19 Oct 2022 21:58:36 +0200 Original-Received: (qmail 24249 invoked by uid 1000); 19 Oct 2022 19:58:36 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:245893 Archived-At: Hello, Eli and Andrea. On Wed, Oct 19, 2022 at 19:11:38 +0000, Andrea Corallo wrote: > Eli Zaretskii writes: > >> Date: Wed, 19 Oct 2022 13:28:42 +0000 > >> From: Alan Mackenzie > >> 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).