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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: WAROQUIERS Philippe <philippe.waroquiers <at> eurocontrol.int>
Cc: 55636 <at> debbugs.gnu.org, jurgen.de-backer.ext <at> eurocontrol.int,
 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 22:10:33 +0300

> From: WAROQUIERS Philippe <philippe.waroquiers <at> eurocontrol.int>
> CC: "DE BACKER Jurgen (EXT)" <jurgen.de-backer.ext <at> eurocontrol.int>,
> 	"55636 <at> debbugs.gnu.org" <55636 <at> debbugs.gnu.org>, VAN VLIERBERGHE Stef
> 	<stef.van-vlierberghe <at> eurocontrol.int>
> Date: Thu, 26 May 2022 17:25:29 +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?

Previous Next

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