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

[Dmitry Gutov <dgutov@yandex.ru>]

On 20/05/2024 05:38, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
>>> 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.
> 
> Rather than a profiler report, maybe a better approach would be to
> remove things from the non-inhibited-modification-hooks paths and see
> how/if they change the performance.
> E.g. replace the `inhibit-modification-hooks` binding by one that binds
> `before/after-change-functions` to nil.
> 
>>> I wonder what we do during those 20% of the time if the buffer is left
>>> in fundamental-mode.
>> Good question.
> 
> It's probably the better case to investigate since it might be easier to
> see the effects.

Revisiting this, I haven't been able to reproduce the 20% number. :-(

The effect of that specific inhibit-modification-hooks binding seems to 
stay around 4-8%, and it's actually on the higher end when the 
set-auto-mode call it present (probably due to text manipulation inside it).

Binding before/after-change-functions, both of the hooks have their 
impact - one more than the other, but like 60/40. Maybe just funcall 
overhead.

>>>>> 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%).
> 
> I guess during printing if it's done in many small steps we may indeed
> run modification hooks many times, so that could explain the
> higher percentage.
> 
> It still seems hard to justify 27% since those modification hooks should
> usually do nothing, AFAICT.  Maybe there's something silly going on.

On this step (xref--show-common-initialize) the numbers still hold, 
however. What's different, is that replacing the 
inhibit-modification-hooks with two (before-change-functions and 
after-change-functions both to nil) doesn't have a similar effect. Which 
makes sense, since the buffer is almost in fundamental-mode, both hooks 
are nil there.

Binding create-lockfiles or select-active-regions to nil doesn't have 
any impact. And replacing the use of all of the above with 
combine-change-calls makes performance worse.

If we're going to continue this subthread, it's probably better to move 
it somewhere else (separate bug, or emacs-devel).