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: David Fussner <dfussner <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53749 <at> debbugs.gnu.org, ikumi <at> ikumi.que.jp, tsdh <at> gnu.org, arash <at> gnu.org, stefankangas <at> gmail.com, dgutov <at> yandex.ru, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Date: Wed, 5 Jun 2024 10:46:10 +0100

[Message part 1 (text/plain, inline)]

Hi Eli, Stefan, and Dmitry,

In case the changeset might prove acceptable for version 30, I attach
the latest patch, which clears out the code I was using to simplify
testing of the AUCTeX modes. I can if requested send a patch for the
manual etags tests, also, in case that might prove helpful down the
line.

Best, David.

On Sat, 25 May 2024 at 12:01, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> How should we proceed about this bug report?  Is David's last
> changeset acceptable or isn't it?
>
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > 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>
> > 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
> >
> >

[0004-Provide-a-modified-xref-backend-for-TeX-buffers.patch (text/x-patch, attachment)]

Previous Next

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