GNU bug report logs - #59738
c-ts-mode is slow with large buffers.

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 59738 <at> debbugs.gnu.org
Subject: bug#59738: c-ts-mode is slow with large buffers.
Date: Tue, 6 Dec 2022 20:56:13 -0800

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Emacs.
>
> In an up to date (2022-11-30) master started as $ emacs --no-desktop:
>
> The file .../drivers/gpu/drm/amd/include/asic_reg/dce/dce_12_0_sh_mask.h
> in the Linux source tree is 6.8 MB big, consisting of a large number of
> #defines and comments, but nothing else.
>
> To scroll through it in c-ts-mode takes a little over 26 minutes on my
> system.  By comparison, in C Mode it takes 31 seconds.  There would
> appear to be a need for some optimisation in c-ts-mode, here.
>
>
> The file
> https://gitlab.com/wireshark/wireshark/-/raw/master/epan/dissectors/packet-rrc.c
> (see bug #45248) (10 MB) takes 578 seconds to scroll in c-ts-mode.  It
> scrolls through the first 83% of the buffer rapidly, then chokes on a big
> brace block initialisation.  Also, the font-locking fails part way
> through this brace block (without any apparent speed up).
>
> For comparison, the scrolling takes 30 seconds in C Mode.  There seems to
> be a need for optimisation of c-ts-mode in this case, too.
>
>
> For completeness, I used M-: (time-scroll) in the following for the
> timings:
>
> (defmacro time-it (&rest forms)
>   "Time the running of a sequence of forms using `float-time'.
> Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
>   `(let ((start (float-time)))
>     ,@forms
>     (- (float-time) start)))
>
> (defun time-scroll (&optional arg)
>   (interactive "P")
>   (message "%s"
>            (time-it
>             (condition-case nil
>                 (while t
>                   (if arg (scroll-down) (scroll-up))
>                   (sit-for 0))
>               (error nil)))))

Ah, the lovely packet-rrc.c file. We had some discussion of it in
bug#59415, basically it contains some syntax that screws tree-sitter up.
The block initialization you see makes tree-sitter into erroneously
generating a very tall tree: it recognizes all the opening bracket and
ignores (almost) all the closing brackets. That causes operations on the
tree to be much much slower than it normally is.

I added some fix so the rest of the file can be largely unaffected, and
reported this problem to tree-sitter-c’s developer (no reply as of now).
There is not much we can do to fix this, and since it’s rare, I think a
user could probably just use c-mode for this kind of files.

Yuan

Previous Next

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