bug#73484: 31.0.50; Abolishing etags-regen-file-extensions

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 6 Oct 2024 03:56:58 +0300
> Cc: spwhitton@spwhitton.name, 73484@debbugs.gnu.org,
>  Eli Zaretskii <eliz@gnu.org>
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 05/10/2024 19:38, Francesco Potortì wrote:
> > Eli Zaretskii:
> >>> How hard is it to add to a live TAGS file fake lines which look like
> >>> this:
> >>>
> >>>     ^L
> >>>     foo,0
> >>>
> >>> (with random strings instead of "foo"), and then time some TAGS-using
> >>> commands with and without these additions?
> > 
> > Dmitry Gutov:
> >> Okay, done that.
> >>
> >> 'M-.' takes more or less the same.
> >>
> >> The file size of TAGS increased from 66 MB to 85 MiB.
> >>
> >> Won't measure time to generate now - because the current method and the
> >> "real" one will be different, but note that it's more relevant with
> >> etags-regen-mode because the scan is performed lazily: every time the
> >> user does the first search in a new project.
> > 
> > Removing the Fortran and C/C++ fallbacks just for testing requires recompiling etags.c after removing the code beginning with /* Else try Fortran or C. */.  This would avoid parsing the file (except for detecting the sharp-bang) and would leave the file name in the tags file, without tags.

That would also remove the ability to scan files of no language for
regexps.  So this is not what I intend to do for this feature request,
FWIW.

> Then, the total time increased a lot: from 30 s to 30-40 min.

I don't understand why.  How many files with no extensions are in that
tree, and what was the etags command line in both cases?

> But parsing HTML files seems to remain the slowest part. There are a lot 
> of them in that project (many test cases), but maybe 3x the number of 
> code files, not 60x their number. And they're pretty small, on average. 
> If somebody wants to test that locally, here's the repository: 
> https://github.com/mozilla/gecko-dev

If HTML files is what explains the slowdown, then why this change
triggered it?  HTML files are supposed to have extensions that tell
etags they are HTML.  And if they don't have extensions, the code you
removed would have caused etags to scan these files anyway, looking
for Fortran or C tags.  So how come the change slowed down etags so
much?  What am I missing?