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

[Eli Zaretskii]

> From: WAROQUIERS Philippe <philippe.waroquiers@eurocontrol.int>
> CC: "DE BACKER Jurgen (EXT)" <jurgen.de-backer.ext@eurocontrol.int>,
>       "55636@debbugs.gnu.org" <55636@debbugs.gnu.org>, VAN VLIERBERGHE Stef
>       <stef.van-vlierberghe@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?