GNU bug report logs -
#55636
27.2; etags performance fix when working with very big TAGS files
Previous Next
Full log
Message #8 received at 55636 <at> debbugs.gnu.org (full text, mbox):
> Cc: jurgen.de-backer.ext <at> eurocontrol.int, stef.van-vlierberghe <at> eurocontrol.int,
> philippe.waroquiers <at> eurocontrol.int
> Date: Wed, 25 May 2022 16:04:04 +0000
> From: Jurgen De Backer via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> We implemented a fix for making etags searching faster in our custom
> emacs build.
> In our project, sometimes a search could take more than 10 seconds.
> The fix is to expand filenames only if they are relative:
>
> (defun expand-if-relative (a-file)
> (if (file-name-absolute-p a-file)
> a-file
> (expand-file-name a-file)
> )
> )
>
> and then use this function in the mapcar statement inside (defun
> tags-table-including ...), replacing expand-file-name:
> ....
> (if (member this-file (mapcar #'expand-if-relative
> (tags-table-files)))
> ;; Found it.
> (setq found tables)
> )
> ....
Thanks. How much speedup does this bring in your use cases? From 10
sec down to how long?
> Looking at expand-file-name doc, it does 2 things:
> * make file name absolute
> * and canonicalize it (removes the xxxx/.. dir components,
> the . dir components, the double slashes).
It actually does more, like resolve the ~/ etc.
> We are wondering if the standard C function in emacs could do
> a fast "do nothing" when the file name is absolute and has
> nothing to cannonicalize.
I think testing for "nothing to canonicalize" is as complex as
canonicalizing the file name.
This bug report was last modified 2 years and 356 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.