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

Previous Next

Full log

Message #124 received at 66117 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: dmitry <at> gutov.dev, 66117 <at> debbugs.gnu.org
Subject: Re: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening
 large number of buffers
Date: Sat, 07 Oct 2023 15:05:35 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: dmitry <at> gutov.dev, 66117 <at> debbugs.gnu.org
> Date: Sat, 07 Oct 2023 11:43:38 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > So in C this is:
> >> >
> >> >   list2 (INT_TO_INTEGER (s.st_ino), INT_TO_INTEGER (s.st_dev));
> >> 
> >> But how to get `s'? Do you mean that we should re-run `sys_fstat' on
> >> every buffer? That's slow (query to FS), isn't it?
> >
> > No, it's very fast, at least on Posix hosts.  But if we decide it
> > isn't fast enough, we can record that in the buffer when the file is
> > visited.
> 
> I am mostly concerned about network FS, where any file operation can be
> slow.

My advice is to have a prototype working, then time it on local
filesystems.  Optimizing for networked filesystems is the next step,
assuming it is needed.  Please keep in mind that the current code does
that as well, only from Lisp: the call to file-attributes calls
'stat', then conses the 11-member list that is the return value.  So
the C implementation cannot possibly be worse.

Previous Next

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