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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 25 May 2024 10:57:22 +0300

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

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  Ikumi Keita <[email-masked]>,  David Fussner
>  <[email-masked]>,  Arash Esbati <[email-masked]>,
>   [email-masked],  Tassilo Horn <[email-masked]>,  Eli Zaretskii
>  <[email-masked]>
> 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
> 
>