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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, 66117@debbugs.gnu.org
> Date: Sat, 07 Oct 2023 09:29:15 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > From my POV, there are two alternatives here:
> >
> >   . expose several new primitives to Lisp to make find-buffer-visiting
> >     faster without changing the way we store the file-to-buffer
> >     association information
> >   . introduce caches or change the way file-to-buffer associations are
> >     stored to speed up find-buffer-visiting
> >
> > What I'd like to see is that someone implements the first idea, and
> > times find-buffer-visiting after that to see if it becomes fast
> > enough.  Then we can discuss whether anything else is needed.
> 
> Agree. That's what I was trying to do. However, one of the new primitives
> will require searching a buffer with given value of `buffer-file-number'
> - the variable not defined in C.

buffer-file-number is defined as follows:

                    (file-attribute-file-identifier
                     (file-attributes buffer-file-name)))

whereas file-attribute-file-identifier is

  (defsubst file-attribute-file-identifier (attributes)
    "The inode and device numbers in ATTRIBUTES returned by `file-attributes'.
  The value is a list of the form (INODENUM DEVICE), where DEVICE could be
  either a single number or a cons cell of two numbers.
  This tuple of numbers uniquely identifies the file."
    (nthcdr 10 attributes))

So in C this is:

  list2 (INT_TO_INTEGER (s.st_ino), INT_TO_INTEGER (s.st_dev));

> >> For example, org-element.el needs to set buffer-local values in base
> >> buffer of an indirect buffer every time buffer text is being edited.
> >
> > And that is performance-critical? in what way and in which situations?
> 
> When making a large number of edits in Org buffer. The code I am
> referring to runs in `after-change-functions' and therefore should be as
> fast as possible.

I'd need to see measurements for that.  In any case, this is a
separate issue.