GNU bug report logs - #53749
29.0.50; [PATCH] Xref backend for TeX buffers

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 53749 <at> debbugs.gnu.org, Ikumi Keita <ikumi <at> ikumi.que.jp>, David Fussner <dfussner <at> googlemail.com>, Arash Esbati <arash <at> gnu.org>, stefankangas <at> gmail.com, Tassilo Horn <tsdh <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.