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 wrote: > > How should we proceed about this bug report? Is David's last > changeset acceptable or isn't it? > > > From: Stefan Monnier > > Cc: 53749@debbugs.gnu.org, Ikumi Keita , David Fussner > > , Arash Esbati , > > stefankangas@gmail.com, Tassilo Horn , Eli Zaretskii > > > > 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 > > > >