[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59738: c-ts-mode is slow with large buffers.
From: |
Alan Mackenzie |
Subject: |
bug#59738: c-ts-mode is slow with large buffers. |
Date: |
Sun, 11 Dec 2022 17:13:49 +0000 |
Hello, Eli.
On Sun, Dec 11, 2022 at 08:45:21 +0200, Eli Zaretskii wrote:
> > Date: Sat, 10 Dec 2022 21:34:20 +0000
> > Cc: Yuan Fu <casouri@gmail.com>, 59738@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > > Thanks, now c-ts-mode is twice as fast as c-mode with that file.
> > > Great job!
> > The bug which was causing it to be very slow is fixed, so I agree,
> > excellent job!
> > But I've measured it as being 62% faster (not twice as fast) as CC Mode.
> > A "normal" C file (xdisp.c) is around 160% faster, i.e. a little over 2½
> > times as fast.
> You do all your measurements in an optimized build of Emacs. I did
> mine in an unoptimized build, something that I need to use all the
> time, even though my production sessions run optimized builds. In an
> unoptimized build CC Mode is extremely slow.
I've built an emacs-29 with CFLAGS='-O0 -g3', --with-native-compilation,
and --with-enable-checking=all. Just about anything is slow in such a
build. For example, converting the org mode manual from .org to .texi
took ~15 minutes in the bootstrap. I think this configuration is close
to your unoptimized build.
Do you really need to run in such a build all the time? We're talking
about an order of magnitude slow-down from an optimized build. Surely
only a tiny portion of bugs actually need this level of pessimisation.
Even a "normal" debugging build (without the --with-enable-checking) is
going to be a factor of ~3 faster, and surely would be suitable for
nearly all debugging.
> For example, just visiting dce_12_0_sh_mask.h file takes a whopping 67
> sec, and M-> immediately after the file is displayed takes another 25
> sec. With c-ts-mode, these numbers are, respectively, 1.8 sec and 2
> sec.
Yes. I saw pretty much the same in my pessimised build. In a normal
build, these operation are ~10 times as fast. Also we're all agreed
dce_12_0_sh_mask.h is an unusual file, both in its content and its size.
> IOW, scrolling through the whole humongous file measures some aspect
> of the redisplay (actually, JIT font-lock) performance, but that is
> not all that matters when one has to edit a file; the above two
> situations are also important use cases.
> However, talking only about speed is looking at this from an incorrect
> aspect, see below.
If I remember rightly, speed was one of the main reasons given for
introducing tree-sitter, though I may well be wrong here.
> > But given how slow CC Mode was held to be, is a factor 2.6 speed-up
> > really all that we were expecting from c-ts-mode? This is the sort of
> > speed-up one would get by replacing a 5 year old machine with a new one,
> > or using an optimised build in place of a debug build.
> Speed is not the main reason why we want to have font-lock and
> indentation based on a parser library. The main reason is
> _correctness_ and _accuracy_. A regexp-based fontification and
> indentation engines will never be able to match parser-based engines,
> because they doesn't really understand the source code.
Given the current CC Mode, any increase in correctness is going to be
marginal, if apparent at all.
> Even when aided by syntax-ppss, they only catch some part of the
> syntax, and none of the semantics.
c-forward-decl-or-cast-1 and friends do analyze semantics; the level of
analysis is part of the reason why CC Mode's fontification isn't fast.
> The hope is that using a parser will allow us to provide much more
> accurate implementations. Whether and how much this hope will
> materialize is yet to be seen, but looking just at the speedup is
> definitely not TRT for assessing the success of this development in
> Emacs.
I see the advantage of the new tree sitter modes more in a reduction of
maintenance burden (though few other people will see this with respect to
CC Mode ;-).
--
Alan Mackenzie (Nuremberg, Germany).
- bug#59738: c-ts-mode is slow with large buffers., (continued)
- bug#59738: c-ts-mode is slow with large buffers., Yuan Fu, 2022/12/06
- bug#59738: c-ts-mode is slow with large buffers., Eli Zaretskii, 2022/12/07
- bug#59738: c-ts-mode is slow with large buffers., Yuan Fu, 2022/12/07
- bug#59738: c-ts-mode is slow with large buffers., Eli Zaretskii, 2022/12/08
- bug#59738: c-ts-mode is slow with large buffers., Alan Mackenzie, 2022/12/10
- bug#59738: c-ts-mode is slow with large buffers., Yuan Fu, 2022/12/10
- bug#59738: c-ts-mode is slow with large buffers., Eli Zaretskii, 2022/12/11
- bug#59738: c-ts-mode is slow with large buffers., Alan Mackenzie, 2022/12/11
- bug#59738: c-ts-mode is slow with large buffers., Dmitry Gutov, 2022/12/11
- bug#59738: c-ts-mode is slow with large buffers., Eli Zaretskii, 2022/12/11
- bug#59738: c-ts-mode is slow with large buffers.,
Alan Mackenzie <=
- bug#59738: c-ts-mode is slow with large buffers., Eli Zaretskii, 2022/12/11
- bug#59738: c-ts-mode is slow with large buffers., Alan Mackenzie, 2022/12/11
- bug#59738: c-ts-mode is slow with large buffers., Eli Zaretskii, 2022/12/11
- bug#59738: c-ts-mode is slow with large buffers., Stefan Kangas, 2022/12/12
bug#59738: c-ts-mode is slow with large buffers., Eli Zaretskii, 2022/12/07