GNU bug report logs - #55636
27.2; etags performance fix when working with very big TAGS files

Previous Next

Package: emacs;

Reported by: Jurgen De Backer <jurgen.de-backer.ext <at> eurocontrol.int>

Date: Wed, 25 May 2022 16:05:02 UTC

Severity: normal

Found in version 27.2

Full log


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

From: WAROQUIERS Philippe <philippe.waroquiers <at> eurocontrol.int>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "55636 <at> debbugs.gnu.org" <55636 <at> debbugs.gnu.org>,
 "DE BACKER Jurgen \(EXT\)" <jurgen.de-backer.ext <at> eurocontrol.int>,
 VAN VLIERBERGHE Stef <stef.van-vlierberghe <at> eurocontrol.int>
Subject: RE: bug#55636: 27.2; etags performance fix when working with very big
 TAGS files
Date: Thu, 26 May 2022 20:45:08 +0000
> > So, what we can observe there is that the C function Fexpand_file_name makes 236_905 calls
> >
> > to Ffind_File_name_handler
> >
> > This Ffind_file_name_handler function makes 1.2 million calls to fast_string_match.
> >
> >
> >
> > On this screenshot, we cannot see the CPU directly consumed by the functions,
> >
> > but looking at the direct cpu shows that expand-file-name  cost is mostly due to the fast_string_match closure
>
> The Lisp profile tells quite a different story: according to that,
> expand-file-name is not a hotspot.
>
> So I still don't see  that expand-file-name is the place to optimize
> your use case.
>
> Did you succeed in reproducing the 10-sec delay with the original
> code, and then ten-fold speedup if expand-file-name is called only on
> non-absolute file names?

I have tried to reproduce the 10 seconds delay to no success.
With or without the expand-file-name called only on non absolute file names,
 I now see emacs always using about 4 seconds of cpu to load the TAGS files.

So, at this point:
   * I do not understand why we observed 3 different speed:
      sub-second, 4 seconds and 10 seconds
   * we now see that loading the TAGS files takes around 4 seconds, so is still a heavy
      operation that maybe could be optimised but not clear anymore what is the
      costly part.

Thanks
Philippe

____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.




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.