GNU bug report logs - #64735
29.0.92; find invocations are ~15x slower because of ignores

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Wed, 19 Jul 2023 21:17:02 UTC

Severity: normal

Found in version 29.0.92

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: dmitry <at> gutov.dev, michael.albinus <at> gmx.de, 64735 <at> debbugs.gnu.org, sbaugh <at> janestreet.com
Subject: bug#64735: 29.0.92; find invocations are ~15x slower because of ignores
Date: Fri, 21 Jul 2023 19:38:08 +0300
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, dmitry <at> gutov.dev,
>  64735 <at> debbugs.gnu.org, sbaugh <at> janestreet.com
> Date: Fri, 21 Jul 2023 16:15:41 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > The figures provided in this thread indicate speedups that are modest
> > at best, so I'm not sure they justify measures which could cause
> > problems (if that indeed could happen).
> 
> Not that modest. Basically, it all depends on how frequently Emacs file API is
> being used. If we take `find-lisp-find-files', which triggers more file
> handler lookup, the difference becomes more significant:
> 
> (benchmark-run-compiled 1 (find-lisp-find-files "/home/yantar92/.data" ""))
> ;; (3.853305824 4 0.9142656910000007)
> (let (file-name-handler-alist) (benchmark-run-compiled 1 (find-lisp-find-files "/home/yantar92/.data" "")))
> ;; (1.545292093 4 0.9098995830000014)

The above just means that find-lisp is not a good way of emulating
Find in Emacs.  It is no accident that it is not used too much.

> In particular, `expand-file-name' is commonly used in the wild to ensure
> that a given path is full. For a single file, it may not add much
> overheads, but it is so common that I believe that it would be worth it
> to make even relatively small improvements in performance.

The Right Way of avoiding unnecessary calls to expand-file-name is to
program dedicated primitives that perform more specialized jobs,
instead of calling existing primitives in some higher-level code.
Then you can avoid these calls altogether once you know that the input
file names are already in absolute form.

IOW, if a specific job, when implemented in Lisp, is not performant
enough, it means implementing it that way is not a good idea.

Disabling file-name-handlers is the wrong way to solve these
performance problems.

> I am pretty sure that file name handlers are checked behind the scenes
> by many other common operations.

I'm pretty sure they aren't.  But every file-related primitive calls
expand-file-name (it must, by virtue of the Emacs paradigm whereby
each buffer "lives" in a different directory), and that's what you
see, by and large.




This bug report was last modified 1 year and 273 days ago.

Previous Next


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