bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Alan Mackenzie]

Hello, Emacs.

Using Emacs master:

c-ts-mode is slow on large C functions when editing towards the end of
such a function.

As an extreme example, there is a function proto_register_rrc in the
file packet-rrc.c which is part of Wireshark.  This file is "available"
from Github, but sadly no longer freely available - you need to allow
Microsoft's scripts to run on your machine.  I'm willing to send this
file by email to anybody who needs it.  It is almost 10 MB in size.

proto_register_rrc is around 50,000 lines long, total size about 2¼ MB.

Near the end of the function, after typing a character, there is a delay
of between 9 and 10 seconds (on my 7 year old machine) before redisplay
happens.  This is too long.  Some optimisation seems needed.

On disabling font-lock-mode, the response becomes instantaneous.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Kévin Le Gouguec]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Emacs.
>
> Using Emacs master:
>
> c-ts-mode is slow on large C functions when editing towards the end of
> such a function.
>
> As an extreme example, there is a function proto_register_rrc in the
> file packet-rrc.c which is part of Wireshark.  This file is "available"
> from Github, but sadly no longer freely available - you need to allow
> Microsoft's scripts to run on your machine.  I'm willing to send this
> file by email to anybody who needs it.  It is almost 10 MB in size.

Assuming we are talking about the same 10 MB file:

  $ wget https://raw.githubusercontent.com/wireshark/wireshark/master/epan/dissectors/packet-rrc.c

or

  $ git clone --depth 1 https://github.com/wireshark/wireshark 
  $ find wireshark -name packet-rrc.c

might help?

I'd suggest heeding that repository's disclaimer and using the canonical
GitLab repo instead of the read-only GitHub mirror, but odds are
gitlab.com's JS won't fare better on the freedom front.  Debian's mirror
might?

https://salsa.debian.org/debian/wireshark/-/blob/debian/master/epan/dissectors/packet-rrc.c

> proto_register_rrc is around 50,000 lines long, total size about 2¼ MB.
>
> Near the end of the function, after typing a character, there is a delay
> of between 9 and 10 seconds (on my 7 year old machine) before redisplay
> happens.  This is too long.  Some optimisation seems needed.
>
> On disabling font-lock-mode, the response becomes instantaneous.

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Eli Zaretskii]

> Date: Mon, 12 Feb 2024 11:30:00 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Using Emacs master:
> 
> c-ts-mode is slow on large C functions when editing towards the end of
> such a function.
> 
> As an extreme example, there is a function proto_register_rrc in the
> file packet-rrc.c which is part of Wireshark.  This file is "available"
> from Github, but sadly no longer freely available - you need to allow
> Microsoft's scripts to run on your machine.  I'm willing to send this
> file by email to anybody who needs it.  It is almost 10 MB in size.
> 
> proto_register_rrc is around 50,000 lines long, total size about 2¼ MB.
> 
> Near the end of the function, after typing a character, there is a delay
> of between 9 and 10 seconds (on my 7 year old machine) before redisplay
> happens.  This is too long.  Some optimisation seems needed.
> 
> On disabling font-lock-mode, the response becomes instantaneous.

Yuan, could you please look into this?

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Yuan Fu]

> On Feb 15, 2024, at 12:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Mon, 12 Feb 2024 11:30:00 +0000
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> Using Emacs master:
>> 
>> c-ts-mode is slow on large C functions when editing towards the end of
>> such a function.
>> 
>> As an extreme example, there is a function proto_register_rrc in the
>> file packet-rrc.c which is part of Wireshark.  This file is "available"
>> from Github, but sadly no longer freely available - you need to allow
>> Microsoft's scripts to run on your machine.  I'm willing to send this
>> file by email to anybody who needs it.  It is almost 10 MB in size.
>> 
>> proto_register_rrc is around 50,000 lines long, total size about 2¼ MB.
>> 
>> Near the end of the function, after typing a character, there is a delay
>> of between 9 and 10 seconds (on my 7 year old machine) before redisplay
>> happens.  This is too long.  Some optimisation seems needed.
>> 
>> On disabling font-lock-mode, the response becomes instantaneous.
> 
> Yuan, could you please look into this?

Oops, didn’t see this. I’ll take a look.

Yuan

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Yuan Fu]

> On Feb 15, 2024, at 8:06 PM, Yuan Fu <casouri@gmail.com> wrote:
> 
> 
> 
>> On Feb 15, 2024, at 12:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>> Date: Mon, 12 Feb 2024 11:30:00 +0000
>>> From: Alan Mackenzie <acm@muc.de>
>>> 
>>> Using Emacs master:
>>> 
>>> c-ts-mode is slow on large C functions when editing towards the end of
>>> such a function.
>>> 
>>> As an extreme example, there is a function proto_register_rrc in the
>>> file packet-rrc.c which is part of Wireshark.  This file is "available"
>>> from Github, but sadly no longer freely available - you need to allow
>>> Microsoft's scripts to run on your machine.  I'm willing to send this
>>> file by email to anybody who needs it.  It is almost 10 MB in size.
>>> 
>>> proto_register_rrc is around 50,000 lines long, total size about 2¼ MB.
>>> 
>>> Near the end of the function, after typing a character, there is a delay
>>> of between 9 and 10 seconds (on my 7 year old machine) before redisplay
>>> happens.  This is too long.  Some optimisation seems needed.
>>> 
>>> On disabling font-lock-mode, the response becomes instantaneous.
>> 
>> Yuan, could you please look into this?
> 
> Oops, didn’t see this. I’ll take a look.

Before we continue, let me note that this seems like another case where tree-sitter-c parser chokes on some extreme C code. Profiler reports shows that almost all time are spent in treesit-parser-root-node, which indicates that all the time are spent parsing the text.

Yuan


        6094  61% - ...
        5542  55%  - self-insert-command
        5542  55%   - electric-indent-post-self-insert-function
        5542  55%    - indent-according-to-mode
        5542  55%     - treesit-indent
        5542  55%      - let*
        5542  55%       - treesit--indent-1
        5542  55%        - let*
        5542  55%         - cond
        5542  55%          - treesit-node-at
        5542  55%           - let*
        5542  55%            - if
        5542  55%             - or
        5542  55%              - treesit-buffer-root-node
        5542  55%               - let*
        5542  55%                - if
        5542  55%                   treesit-parser-root-node
         552   5%  + #<compiled 0x1812af33e570332e>
        3834  38% - redisplay_internal (C function)
        3824  38%  - redisplay--pre-redisplay-functions
        3824  38%   - run-hook-with-args
        3824  38%    - treesit--pre-redisplay
        3824  38%     - if
        3824  38%      - let
        3824  38%       - while
        3824  38%        - let
        3824  38%           treesit-parser-root-node
           5   0% + command-execute
           5   0% + timer-event-handler

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Mon, 19 Feb 2024 21:49:26 -0800
> Cc: Alan Mackenzie <acm@muc.de>,
>  69071@debbugs.gnu.org
> 
> Before we continue, let me note that this seems like another case where tree-sitter-c parser chokes on some extreme C code. Profiler reports shows that almost all time are spent in treesit-parser-root-node, which indicates that all the time are spent parsing the text.

So maybe this is something to report to tree-sitter and/or
tree-sitter-c developers?  (Does c++-ts-mode behave better with this
file?)

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Yuan Fu]

> On Feb 20, 2024, at 5:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Mon, 19 Feb 2024 21:49:26 -0800
>> Cc: Alan Mackenzie <acm@muc.de>,
>> 69071@debbugs.gnu.org
>> 
>> Before we continue, let me note that this seems like another case where tree-sitter-c parser chokes on some extreme C code. Profiler reports shows that almost all time are spent in treesit-parser-root-node, which indicates that all the time are spent parsing the text.
> 
> So maybe this is something to report to tree-sitter and/or
> tree-sitter-c developers?  (Does c++-ts-mode behave better with this
> file?)

We could, but honestly I don’t think they can/want to do anything.

Yuan

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 24 Feb 2024 12:35:50 -0800
> Cc: acm@muc.de,
>  69071@debbugs.gnu.org
> 
> 
> 
> > On Feb 20, 2024, at 5:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Yuan Fu <casouri@gmail.com>
> >> Date: Mon, 19 Feb 2024 21:49:26 -0800
> >> Cc: Alan Mackenzie <acm@muc.de>,
> >> 69071@debbugs.gnu.org
> >> 
> >> Before we continue, let me note that this seems like another case where tree-sitter-c parser chokes on some extreme C code. Profiler reports shows that almost all time are spent in treesit-parser-root-node, which indicates that all the time are spent parsing the text.
> > 
> > So maybe this is something to report to tree-sitter and/or
> > tree-sitter-c developers?  (Does c++-ts-mode behave better with this
> > file?)
> 
> We could, but honestly I don’t think they can/want to do anything.

I suggest to report this anyway: we don't have anything to lose, and
there's a chance they would like to do something.

Thanks.

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Yuan Fu]

> On Feb 24, 2024, at 9:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 24 Feb 2024 12:35:50 -0800
>> Cc: acm@muc.de,
>> 69071@debbugs.gnu.org
>> 
>> 
>> 
>>> On Feb 20, 2024, at 5:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>>> From: Yuan Fu <casouri@gmail.com>
>>>> Date: Mon, 19 Feb 2024 21:49:26 -0800
>>>> Cc: Alan Mackenzie <acm@muc.de>,
>>>> 69071@debbugs.gnu.org
>>>> 
>>>> Before we continue, let me note that this seems like another case where tree-sitter-c parser chokes on some extreme C code. Profiler reports shows that almost all time are spent in treesit-parser-root-node, which indicates that all the time are spent parsing the text.
>>> 
>>> So maybe this is something to report to tree-sitter and/or
>>> tree-sitter-c developers?  (Does c++-ts-mode behave better with this
>>> file?)
>> 
>> We could, but honestly I don’t think they can/want to do anything.
> 
> I suggest to report this anyway: we don't have anything to lose, and
> there's a chance they would like to do something.
> 
> Thanks.

I created an issue here: https://github.com/tree-sitter/tree-sitter-c/issues/196

Hopefully it captures the issue.

Yuan

bug#69071: Emacs master branch: c-ts-mode is slow with large C functions.

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 29 Feb 2024 17:26:50 -0800
> Cc: acm@muc.de,
>  69071@debbugs.gnu.org
> 
> > I suggest to report this anyway: we don't have anything to lose, and
> > there's a chance they would like to do something.
> > 
> > Thanks.
> 
> I created an issue here: https://github.com/tree-sitter/tree-sitter-c/issues/196
> 
> Hopefully it captures the issue.

Thanks, let's hope indeed.