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.