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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 6 Oct 2024 22:14:46 +0300
> Cc: pot@gnu.org, spwhitton@spwhitton.name, 73484@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 06/10/2024 09:22, Eli Zaretskii wrote:
> 
> >> 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?
> 
> Sorry, I have to add a correction: it's about 15 min either way. Seems 
> like the first time I either messed up the start time, or the directory 
> was in "cold" cache, or the used etags some much older version.
> 
> So to reiterate: the current etags-regen scans in around 30s, and the 
> simple switch scans the directory in 15 minutes. Retesting the change 
> from previous email, it doesn't really help.

Can you please show the etags command line in each of these two cases
that you are comparing?

> > 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?
> 
> I think it would also concern "unknown" extensions, right? Like .txt, 
> .png and so on.

I have difficulty reasoning about this without knowing the command
lines you used.  E.g., I don't understand why in one case it would
scan files with unknown extensions that were not scanned in the other.