GNU bug report logs - #80108
31.0.50; c-ts-mode is really slow with moderately long files. Is this a regression?

Previous Next

To reply to this bug, email your comments to 80108 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <vincenzo.pupillo <at> lpsd.it>
To: bug-gnu-emacs <at> gnu.org
Cc: Yuan Fu <casouri <at> gmail.com>
Subject: 31.0.50;
 c-ts-mode is really slow with moderately long files. Is this a regression?
Date: Thu, 01 Jan 2026 22:09:43 +0100

[Message part 1 (text/plain, inline)]

--text follows this line--
Ciao, first of all, Happy New Year to everyone.
I've been using c-ts-mode to edit C files for a while now. It's always seemed 
faster than c-mode, but I think I've run into some special cases. Specifically, 
these are files containing assets, in this case a font. I tried opening the 
same files with nvim and Zed but didn't encounter the same problem, so it 
doesn't seem to be due to the tree-sitter parser. It seems like a regression 
to me, what do you think?

Attached are the profiler results and the file I mentioned (it comes from 
thorvg.janitor). As a test, you can also use kb_text_shape.h, which comes from 
https://github.com/JimmyLefevre/kb/ and is just 27,686 lines of code.
Thank you.

Vincenzo


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.51, cairo version 1.18.4) of 2026-01-01 built on fedora
Repository revision: 17ddfd66e65c19f44dee41ee1b7ee1ce23ef3ed2
Repository branch: master
System Description: Fedora Linux 43 (KDE Plasma Desktop Edition)

Configured using:
 'configure --disable-gc-mark-trace --with-native-compilation=aot
 --with-tree-sitter --with-cairo --with-x-toolkit=gtk3 --without-pop
 --without-imagemagick --prefix=/opt/emacs_pgtk
 --with-file-notification=inotify --enable-link-time-optimization
 --with-native-compilation --with-xinput2 --with-pgtk 'CFLAGS=-O2
 -march=native -mtune=native -pipe ''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: it_IT.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: C/*

Minor modes in effect:
  flymake-mode: t
  global-completion-preview-mode: t
  completion-preview-mode: t
  override-global-mode: t
  which-key-mode: t
  which-function-mode: t
  fido-vertical-mode: t
  icomplete-vertical-mode: t
  icomplete-mode: t
  fido-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-nonselected-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr noutline outline send-to emacsbug message
yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg
rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mailabbrev
gmm-utils mailheader sendmail mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils misearch multi-isearch help-fns
radix-tree cus-edit pp cus-start cus-load wid-edit c++-ts-mode c-ts-mode
c-ts-common treesit flymake-cc vc-git diff-mode track-changes files-x
vc-dispatcher cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs time add-log elisp-scope comp-run
comp-common rx time-date checkdoc lisp-mnt flymake project compile
text-property-search comint ansi-osc ansi-color ring warnings thingatpt
completion-preview edmacro kmacro cl-extra help-mode
use-package-bind-key bind-key easy-mmode use-package-core which-key
which-func imenu icomplete xr-autoloads package browse-url xdg url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win touch-screen pgtk-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process tty-child-frames
native-compile emacs)

[memory.profile (text/plain, attachment)]

[cpu.profile (text/plain, attachment)]

[assets.h (text/x-chdr, attachment)]

Message #8 received at 80108 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincenzo Pupillo <vincenzo.pupillo <at> lpsd.it>,
 Yuan Fu <casouri <at> gmail.com>
Cc: 80108 <at> debbugs.gnu.org
Subject: Re: bug#80108: 31.0.50;
 c-ts-mode is really slow with moderately long files. Is this a
 regression?
Date: Fri, 02 Jan 2026 09:18:38 +0200

> Cc: Yuan Fu <casouri <at> gmail.com>
> From: Vincenzo Pupillo <vincenzo.pupillo <at> lpsd.it>
> Date: Thu, 01 Jan 2026 22:09:43 +0100
> 
> I've been using c-ts-mode to edit C files for a while now. It's always seemed 
> faster than c-mode, but I think I've run into some special cases. Specifically, 
> these are files containing assets, in this case a font. I tried opening the 
> same files with nvim and Zed but didn't encounter the same problem, so it 
> doesn't seem to be due to the tree-sitter parser. It seems like a regression 
> to me, what do you think?
> 
> Attached are the profiler results and the file I mentioned (it comes from 
> thorvg.janitor). As a test, you can also use kb_text_shape.h, which comes from 
> https://github.com/JimmyLefevre/kb/ and is just 27,686 lines of code.

Looks like some kind of regression, indeed: Emacs 30.2 is much faster
with this file than the current master, using the same language
grammar library.

Yuan, please look into this.

Message #11 received at 80108 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Vincenzo Pupillo <vincenzo.pupillo <at> lpsd.it>
Cc: 80108 <at> debbugs.gnu.org
Subject: Re: bug#80108: 31.0.50; c-ts-mode is really slow with moderately long
 files. Is this a regression?
Date: Fri, 2 Jan 2026 00:58:45 -0800

> On Jan 1, 2026, at 1:09 PM, Vincenzo Pupillo <vincenzo.pupillo <at> lpsd.it> wrote:
> 
> --text follows this line--
> Ciao, first of all, Happy New Year to everyone.
> I've been using c-ts-mode to edit C files for a while now. It's always seemed 
> faster than c-mode, but I think I've run into some special cases. Specifically, 
> these are files containing assets, in this case a font. I tried opening the 
> same files with nvim and Zed but didn't encounter the same problem, so it 
> doesn't seem to be due to the tree-sitter parser. It seems like a regression 
> to me, what do you think?
> 
> Attached are the profiler results and the file I mentioned (it comes from 
> thorvg.janitor). As a test, you can also use kb_text_shape.h, which comes from 
> https://github.com/JimmyLefevre/kb/ and is just 27,686 lines of code.
> Thank you.
> 
> Vincenzo

Thanks, this is indeed a regression, one cause by my recent changes, nonetheless. I pushed a change to address it. The change fixed the slow-down for me, but I don’t know if we’re facing the same issue. Quoting the commit message:

The direct cause of the problem in the bug report is that when
user runs treesit-font-lock-recompute-features to add the
emacs-devel feature in c-ts-mode's mode hook, the added query
for emacs-devel aren't compiled.

This change consists of two parts:
1. The immediate fix: validate and compile queries in
treesit-font-lock-recompute-features.
2. To make it more fool-proof, change treesit-font-lock-rules
back to compile the queries and make
treesit--compile-query-with-cache support compiled queries. This
way, as long as the query goes through treesit-font-lock-rules,
it'll be compiled eventually and not cause slow-down. I had to
add some c-level functions, but they're kind of overdue anyway,
so I don't have any problem adding them to the API.

Yuan

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Yuan Fu <casouri <at> gmail.com>, 80108 <at> debbugs.gnu.org
Subject: Re: bug#80108: 31.0.50;
 c-ts-mode is really slow with moderately long files. Is this a regression?
Date: Fri, 02 Jan 2026 17:35:58 +0100

[Message part 1 (text/plain, inline)]

Ciao Yuan, it's definitely better than yesterday, although slightly slower than 
c-mode, thank you!  But now there's a strange problem, though I don't 
understand how it could be related:
I open the assets.h file and scroll up and down a few times, then run M-x find-
library and emacs freezes for a few seconds. 
The CPU profiler, activated just before running `find-library`, shows a call to 
the functions `treesit-forward-sexp-list' and `treesit--forward-list-with-
default' that shouldn't be there, I think. Attached are the CPU and memory 
profiler reports. 

Thanks.

Vincenzo

In data venerdì 2 gennaio 2026 09:58:45 Ora standard dell’Europa centrale, 
Yuan Fu ha scritto:
> > On Jan 1, 2026, at 1:09 PM, Vincenzo Pupillo <vincenzo.pupillo <at> lpsd.it>
> > wrote:
> > 
> > --text follows this line--
> > Ciao, first of all, Happy New Year to everyone.
> > I've been using c-ts-mode to edit C files for a while now. It's always
> > seemed faster than c-mode, but I think I've run into some special cases.
> > Specifically, these are files containing assets, in this case a font. I
> > tried opening the same files with nvim and Zed but didn't encounter the
> > same problem, so it doesn't seem to be due to the tree-sitter parser. It
> > seems like a regression to me, what do you think?
> > 
> > Attached are the profiler results and the file I mentioned (it comes from
> > thorvg.janitor). As a test, you can also use kb_text_shape.h, which comes
> > from https://github.com/JimmyLefevre/kb/ and is just 27,686 lines of
> > code. Thank you.
> > 
> > Vincenzo
> 
> Thanks, this is indeed a regression, one cause by my recent changes,
> nonetheless. I pushed a change to address it. The change fixed the
> slow-down for me, but I don’t know if we’re facing the same issue. Quoting
> the commit message:
> 
> The direct cause of the problem in the bug report is that when
> user runs treesit-font-lock-recompute-features to add the
> emacs-devel feature in c-ts-mode's mode hook, the added query
> for emacs-devel aren't compiled.
> 
> This change consists of two parts:
> 1. The immediate fix: validate and compile queries in
> treesit-font-lock-recompute-features.
> 2. To make it more fool-proof, change treesit-font-lock-rules
> back to compile the queries and make
> treesit--compile-query-with-cache support compiled queries. This
> way, as long as the query goes through treesit-font-lock-rules,
> it'll be compiled eventually and not cause slow-down. I had to
> add some c-level functions, but they're kind of overdue anyway,
> so I don't have any problem adding them to the API.
> 
> Yuan

[memory2.profile (text/plain, attachment)]

[cpu2.profile (text/plain, attachment)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#80108: 31.0.50;
 c-ts-mode is really slow with moderately long files. Is this a regression?
Date: Fri, 02 Jan 2026 17:59:15 +0100

Okay, I found another problem: Emacs freezes if you go to the end of the 
assets.h file, on the last curly bracket, and then execute `backward-sexp'.

Vincenzo

In data venerdì 2 gennaio 2026 17:35:58 Ora standard dell’Europa centrale, hai 
scritto:
> Ciao Yuan, it's definitely better than yesterday, although slightly slower
> than c-mode, thank you!  But now there's a strange problem, though I don't
> understand how it could be related:
> I open the assets.h file and scroll up and down a few times, then run M-x
> find- library and emacs freezes for a few seconds.
> The CPU profiler, activated just before running `find-library`, shows a call
> to the functions `treesit-forward-sexp-list' and
> `treesit--forward-list-with- default' that shouldn't be there, I think.
> Attached are the CPU and memory profiler reports.
> 
> Thanks.
> 
> Vincenzo
> 
> In data venerdì 2 gennaio 2026 09:58:45 Ora standard dell’Europa centrale,
> 
> Yuan Fu ha scritto:
> > > On Jan 1, 2026, at 1:09 PM, Vincenzo Pupillo <vincenzo.pupillo <at> lpsd.it>
> > > wrote:
> > > 
> > > --text follows this line--
> > > Ciao, first of all, Happy New Year to everyone.
> > > I've been using c-ts-mode to edit C files for a while now. It's always
> > > seemed faster than c-mode, but I think I've run into some special cases.
> > > Specifically, these are files containing assets, in this case a font. I
> > > tried opening the same files with nvim and Zed but didn't encounter the
> > > same problem, so it doesn't seem to be due to the tree-sitter parser. It
> > > seems like a regression to me, what do you think?
> > > 
> > > Attached are the profiler results and the file I mentioned (it comes
> > > from
> > > thorvg.janitor). As a test, you can also use kb_text_shape.h, which
> > > comes
> > > from https://github.com/JimmyLefevre/kb/ and is just 27,686 lines of
> > > code. Thank you.
> > > 
> > > Vincenzo
> > 
> > Thanks, this is indeed a regression, one cause by my recent changes,
> > nonetheless. I pushed a change to address it. The change fixed the
> > slow-down for me, but I don’t know if we’re facing the same issue. Quoting
> > the commit message:
> > 
> > The direct cause of the problem in the bug report is that when
> > user runs treesit-font-lock-recompute-features to add the
> > emacs-devel feature in c-ts-mode's mode hook, the added query
> > for emacs-devel aren't compiled.
> > 
> > This change consists of two parts:
> > 1. The immediate fix: validate and compile queries in
> > treesit-font-lock-recompute-features.
> > 2. To make it more fool-proof, change treesit-font-lock-rules
> > back to compile the queries and make
> > treesit--compile-query-with-cache support compiled queries. This
> > way, as long as the query goes through treesit-font-lock-rules,
> > it'll be compiled eventually and not cause slow-down. I had to
> > add some c-level functions, but they're kind of overdue anyway,
> > so I don't have any problem adding them to the API.
> > 
> > Yuan

Previous Next

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