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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Also, even `find-file-noselect' does not use
>> `set-visited-file-name'.
>
> Why does it matter?  We need to catch this in find-file-noselect and
> in set-visited-file-name anyway.

Mostly because I feel that I misunderstand where `buffer-file-name' is
set. `find-file-noselect-1' only sets `buffer-file-name' when

      (if find-file-visit-truename ;; defcustom, nil by default
          (setq buffer-file-name (expand-file-name buffer-file-truename)))

>>   - ~find-alternate-file~
>>   - ~find-file-noselect-1~ (but not by default?)
>>   - ~set-visited-file-name~
>>   - ~file-name-non-special~
>
> These _must_ update the cache.

I feel that I am still missing where `buffer-file-name' is set when
opening file via C-x C-f. Debugger showed something weird in my testing.

>> - Functions setting ~buffer-file-truename~ manually (except those setting it 
>> to nil):
>
> Are the cases where we find the buffer via file's truename significant
> in the profiles you've seen?

Not significant for the profiles I got, but I did not want to break the
existing code.

> ... if not, these functions are not relevant
> to the issue at hand.  If the search by truename _is_ significant, we
> could cache that as well.

Just to make sure that we are on the same page: the cache I am proposing
should be complete - if a buffer is missing from the cache, we should be
sure that there is no matching buffer.

`find-buffer-visiting' explicitly checks for `buffer-file-truename'.
So, if the cache does not account for `buffer-file-truename', there will
be divergence between the existing code and when using the cache.

Same argument for `buffer-file-number'

>> > Programs that make these changes are asking for trouble, IMO.  AFAICT,
>> > find-buffer-visiting will never find such buffers anyway.
>> 
>> It would, in its current form. Because it calls `get-file-buffer' that
>> loops over all the buffers and checks their buffer-local
>> `buffer-file-name' value, including values set via `setq' in Elisp.
>
> Again, which of the loops took the significant time in the profiles
> you have? the one in get-file-buffer or the ones in
> find-buffer-visiting?

Most of the time was taken by `find-buffer-visiting'. Replacing
`find-buffer-visiting' with `get-file-buffer' in certain (not all)
places reduced the total runtime by 30%. I do not have more granular data
because the profiler did not give very granular data for the internals
of `find-buffer-visiting'.

I will try to setup a test on my machine for more detailed data.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>