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

[Eli Zaretskii]

How should we proceed about this bug report?  Is David's last
changeset acceptable or isn't it?

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 53749@debbugs.gnu.org,  Ikumi Keita <ikumi@ikumi.que.jp>,  David Fussner
>  <dfussner@googlemail.com>,  Arash Esbati <arash@gnu.org>,
>   stefankangas@gmail.com,  Tassilo Horn <tsdh@gnu.org>,  Eli Zaretskii
>  <eliz@gnu.org>
> Date: Sun, 19 May 2024 22:38:45 -0400
> 
> >> 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.
> 
> >>>> 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.
> 
> 
>         Stefan
> 
>