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

[WAROQUIERS Philippe via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> > 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.