GNU bug report logs - #66117
30.0.50; `find-buffer-visiting' is slow when opening large number of buffers

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: yantar92 <at> posteo.net
Cc: dmitry <at> gutov.dev, 66117 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large number of buffers
Date: Sat, 30 Dec 2023 12:10:33 +0200

> Cc: dmitry <at> gutov.dev, 66117 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Sat, 30 Dec 2023 11:50:02 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Cc: dmitry <at> gutov.dev, 66117 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> > Date: Sat, 30 Dec 2023 10:08:34 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > 
> > > From: Ihor Radchenko <yantar92 <at> posteo.net>
> > > Cc: monnier <at> iro.umontreal.ca, dmitry <at> gutov.dev, 66117 <at> debbugs.gnu.org
> > > Date: Fri, 29 Dec 2023 13:55:45 +0000
> > > 
> > > Eli Zaretskii <eliz <at> gnu.org> writes:
> > > 
> > > >> No. I just had a problem with my local git repo. git reset fixed it and
> > > >> revealed that the patch is indeed not installed yet.
> > > >
> > > > Is that patch still valid, or do you need to rebase it?  Would you
> > > > like to repost it?
> > > 
> > > All the three patches I submitted in this thread are cleanly applying
> > > onto freshly cloned master.
> > 
> > Thanks, I installed them.
> > 
> > Should we now close this bug?
> 
> Ehmm...  I see that test/src/buffer-tests now have 5 failures that
> were not there before:
> 
>   5 unexpected results:
>      FAILED  test-buffer-modifications
>      FAILED  test-kill-buffer-auto-save-default
>      FAILED  test-kill-buffer-auto-save-delete-no
>      FAILED  test-kill-buffer-auto-save-delete-yes
>      FAILED  test-restore-buffer-modified-p
> 
> Also, 7 of the lisp/files-test fail:
> 
>   7 unexpected results:
>      FAILED  files-tests-bug-18141
>      FAILED  files-tests-file-name-non-special-make-auto-save-file-name
>      FAILED  files-tests-file-name-non-special-set-visited-file-modtime
>      FAILED  files-tests-no-file-write-contents
>      FAILED  files-tests-revert-buffer
>      FAILED  files-tests-revert-buffer-with-fine-grain
>      FAILED  files-tests-zzdont-rewrite-precious-files
> 
> Could you please look into these?  (Interestingly, those 5+7 don't
> fail for me on MS-Windows, only on GNU/Linux...)

I think at least part of the problem is in this fragment from
find-file-noselect:

	     ;; Find any buffer for a file that has same truename.
	     (other (and (not buf)
                         (find-buffer-visiting
                          filename
                          ;; We want to filter out buffers that we've
                          ;; visited via symlinks and the like, where
                          ;; the symlink no longer exists.
                          (lambda (buffer)
                            (let ((file (buffer-local-value
                                         'buffer-file-name buffer)))
                              (and file (file-exists-p file))))))))

This call to find-buffer-visiting fails because file-exists-p is
called with a nil argument:

  Test test-buffer-modifications backtrace:
    file-exists-p(nil)
    find-buffer-visiting("/tmp/emacs-test-MzitxT-buffer" #f(compiled-fun
    find-file-noselect("/tmp/emacs-test-MzitxT-buffer" nil nil nil)
    find-file("/tmp/emacs-test-MzitxT-buffer")

Please attend to this as soon as you can, because I think this same
problem will break many other use cases.

(I guess this doesn't happen on Windows because the involved
files/directories are not symlinks.)

Previous Next

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