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

[Eli Zaretskii]

> From: VAN VLIERBERGHE Stef <stef.van-vlierberghe@eurocontrol.int>
> CC: "55636@debbugs.gnu.org" <55636@debbugs.gnu.org>, WAROQUIERS Philippe
>       <philippe.waroquiers@eurocontrol.int>
> Date: Wed, 25 May 2022 20:42:16 +0000
> 
> For us the 10 sec is reduced to below 1 sec, loading the tags file is no 
> longer noticed after this change.
> 
> I assume the reason is a huge amount of files all accessed over NFS, and 
> expand-file-name does a lot of system calls that translate into network 
> packets.

Actually, expand-file-name is a purely syntactical function that is
supposed not to hit the filesystem at all, at l;east on Posix systems.
So I wonder why it seems to happen in your case.  Any chances that you
could show a trace of system calls for those 10 sec?

Of course, making a simple change that you suggested is a no-brainer,
so we might as well do it without further ado, but I'm just curious
and think maybe we will learn something useful if we dig a bit deeper
into your use case.

> An alternative approach is to add some switch that allows a customization 
> that simply never calls the expand-file-name, we generate tags files that 
> already contain absolute paths so don't need any of this logic and disabling 
> it would also be ok for us.

That'd be less clean, I think: if we can do something automatically,
it's better to do that instead of placing the burden on the user.

Again, I'm not asking these questions because I see some problem in
your proposed change.  If we arrive at the conclusion that there's no
reason to investigate more, we can just install that change, as it
cannot possibly hurt.

Thanks.