bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large number of buffers
Date: Sun, 08 Oct 2023 12:56:23 +0300

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, 66117@debbugs.gnu.org
> Date: Sun, 08 Oct 2023 09:00:49 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > My advice is to have a prototype working, then time it on local
> > filesystems.
> 
> See the attached patch.

Thanks.  This still has some unnecessary overhead (I actually thought
about moving the entire find-buffer-visiting into C, not replacing it
with Lisp that calls new primitives).  But this already makes
find-buffer-visiting take an insignificant portion of CPU time, so I
think it proves that the idea is workable:

> I left the `file-attributes' call in Elisp. Looking at the
> cpu-profiler-w-patch, `find-buffer-visiting' is no longer the main
> contributor to CPU time. I am not sure if we really need to squeeze the
> performance yet further from `find-buffer-visiting' - `file-attributes'
> is taking pretty much no time:
> 
> (reverse call-tree)
>          924  36%   Automatic GC
>          173   6% + inhibit-local-variables-p
>          172   6% + locate-dominating-file
>          139   5% + abbreviate-file-name
>          113   4% + dir-locals--all-files
>          109   4% + file-truename
>           92   3% + find-buffer-visiting 
> ...
>            6   0% + file-attributes 
> 
> comapare with cpu-profiler-without-patch:
> 
> (reverse call-tree)
>         1714  39% + find-buffer-visiting
>         1131  26%   Automatic GC
>          202   4% + locate-dominating-file
>          147   3% + abbreviate-file-name
>          140   3% + inhibit-local-variables-p
>          104   2% + dir-locals--all-files
>           98   2% + uniquify-rationalize-file-buffer-names
>           91   2% + file-truename





reply via email to

[Prev in Thread] Current Thread [Next in Thread]