Subject: Re: bug#55636: 27.2; etags performance fix when working with very big TAGS files

From: Eli Zaretskii <[email-masked]>
Date: Thu, 26 May 2022 22:10:33 +0300

> From: WAROQUIERS Philippe <[email-masked]>
> CC: "DE BACKER Jurgen (EXT)" <[email-masked]>,
> 	"[email-masked]" <[email-masked]>, VAN VLIERBERGHE Stef
> 	<[email-masked]>
> 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?