GNU bug report logs - #78665
31.0.50; Very slow saves

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78665 <at> debbugs.gnu.org
Subject: bug#78665: 31.0.50; Very slow saves
Date: Mon, 02 Jun 2025 09:10:05 +0300

> Cc: monnier <at> iro.umontreal.ca
> Date: Sun, 01 Jun 2025 16:06:53 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Package: Emacs
> Version: 31.0.50
> 
> 
> The last few weeks I noticed that saving a buffer was sometimes taking
> a very long time (like more than 10s).  I finally managed to catch it
> in the act while running the profiler, and it seems to have something to
> do with `outline--hidden-headings-restore-paths`:
> 
>         9630  75% - command-execute
>         9630  75%  - call-interactively
>         8638  67%   - funcall-interactively
>         8630  67%    - save-buffer
>         8630  67%     - basic-save-buffer
>         8607  67%      - run-hooks
>         8607  67%       - vc-git-resolve-when-done
>         8593  67%        - vc-resynch-buffer
>         8593  67%         - vc-resynch-window
>         8593  67%          - vc-revert-buffer-internal
>         8593  67%           - revert-buffer
>         8353  65%            - mapc
>         8353  65%             - funcall
>         8353  65%              - #<byte-code-function 1FB>
>         8353  65%               - outline--hidden-headings-restore-paths
>         8353  65%                - outline-map-region
>         7748  60%                 - #<byte-code-function 28A>
>         7732  60%                  - outline-hide-subtree
>         7728  60%                   - outline-flag-subtree
>         4268  33%                    + outline-back-to-heading
>         3393  26%                    + outline-end-of-subtree
>           63   0%                    + outline-flag-region
>            4   0%                    + outline-end-of-heading
>            8   0%                  + mapcar
>            4   0%                    gethash
>            4   0%                    pos-bol
>          605   4%                 + outline-next-heading
>          232   1%            + run-hook-wrapped
>            8   0%            + revert-buffer--default
>           14   0%          re-search-forward
>           16   0%      + basic-save-buffer-1
>            4   0%      + vc-before-save
>            3   0%      + vc-after-save
>            8   0%    + execute-extended-command
>          992   7%   + byte-code
>         1855  14% + redisplay_internal (C function)
>         1166   9% + #<byte-code-function 6A0>
>           45   0% + timer-event-handler
>            4   0% + jit-lock--antiblink-post-command
>            4   0% + reveal-post-command
>            0   0%   ...
> 
> This one occurred while saving `transient.el`.
> 
> Maybe we could avoid the whole thing by changing VC to not
> `revert-buffer` (AFAIK this was done to handle the case where CVS/RCS
> would update the "keywords" in the file to reflect its new state, but
> I believe this is basically never done nowadays).
> 
> But in any case `outline--hidden-headings-restore-paths` just takes too
> much time.

Two questions:

  . was this file under Git, and if not, how did
    vc-git-resolve-when-done come into play?
  . why does vc-revert-buffer-internal ended up calling
    outline--hidden-headings-restore-paths? was outline-minor-mode
    active in the buffer?

IOW, I'd like to better understand the scope of the use cases where
saving a buffer is now so much slower.  (How large was the buffer,
btw?)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.