bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers

[Dmitry Gutov <dgutov@yandex.ru>]

On 16/05/2024 21:18, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
>>> IIUC, in the `syntax-needed` case, the let-binding of
>>> `inhibit-modification-hooks` is just not useful very (4-7% is not worth
>>> the trouble), so its purpose is to speed up the other case.
>> 4-10% is the improvement for both cases (the "syntax needed" and not).
> 
> Hmm... not sure it's worth the trouble, then.
> Also, it might be worth trying to see where those 4-10% are spent: this
> is done in a temp buffer where there should presumably be very little
> need for before/after-change-functions, so maybe we can get rid of the
> specific offenders rather than inhibit all modification hooks.

Given the relatively low percentages, it might be difficult to glance 
from a profiler report. I was assuming the time was mostly spent in 
syntax-ppss-flush-cache, but the function is pretty simple.

>> Also, I'm eyeing another performance improvement (simplifying file type
>> detection) - the call to set-auto-mode is not fast. Simply commenting this
>> call out improves the performance by 4x or so - but we'll need a simpler
>> version of it instead, of course.
>>
>> And with the above change (commenting out the set-auto-mode call), the
>> difference that the inhibit-modification-hooks hack makes is amplified: it
>> can get up to 20%.
> 
> I wonder what we do during those 20% of the time if the buffer is left
> in fundamental-mode.

Good question.

>>> Also, what about the other two bindings of `inhibit-modification-hooks`?
>> The other two are used while the contents of the Xref buffer are printed (or
>> re-printed), so there's none of the syntax-ppss complications there. The
>> performance difference is 8.5% in my last measurement.
> 
> Is this 8.5% of a function that's fast anyway of 8.5% of a function
> which takes a fair bit of time?

When there are a lot of matches, it can take some time. Note that 100% 
in this case is the whole list-files-do-search-print-results pipeline, 
not just the printing phase. So printing is sped up by more than 8% (my 
last test says it's by 27%).

> But as a start, every such binding should have a comment
> mentioning that it's there only to gain a few percents of performance.

Sure.