bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Date: Thu, 16 May 2024 14:18:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

>> IIUC, in the `syntax-needed` case, the let-binding of
>> `inhibit-modification-hooks` is just not useful very (4-7% is not worth
>> the trouble), so its purpose is to speed up the other case.
> 4-10% is the improvement for both cases (the "syntax needed" and not).

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.

> Also, I'm eyeing another performance improvement (simplifying file type
> detection) - the call to set-auto-mode is not fast. Simply commenting this
> call out improves the performance by 4x or so - but we'll need a simpler
> version of it instead, of course.
>
> And with the above change (commenting out the set-auto-mode call), the
> difference that the inhibit-modification-hooks hack makes is amplified: it
> can get up to 20%.

I wonder what we do during those 20% of the time if the buffer is left
in fundamental-mode.

>> 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?  Again, I'm not sure it's worth
the trouble.  But as a start, every such binding should have a comment
mentioning that it's there only to gain a few percents of performance.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]