* bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag
@ 2024-11-14 20:39 Björn Lindqvist
2024-11-15 7:40 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Björn Lindqvist @ 2024-11-14 20:39 UTC (permalink / raw)
To: 74357
This bug has been present in c-mode for at least a year, but I haven't
gotten around to report it. The reason is that bugs about latency are
erratic and tricky to triage. Typing when the cursor is on some
syntatic constructs in c-mode causes severe lag on the order of several
hundred milliseconds on my (admittedly slow) laptop. The lag
makes c-mode almost unusable. Here is an MWE:
void foo(uint dc_dim, uint sc_dim,
uint fy_dim, uint fx_dim,
__global const float * restrict F,
uint sy_dim, uint sx_dim,
__global const float * restrict S,
uint padding,
__global float * restrict D) {
uint dy_dim = sy_dim + 2 * padding - fy_dim + 1;
uint dx_dim = sx_dim + 2 * padding - fx_dim + 1;
// Place cursor at "y" in "dy_dim". Hold "y" and observe lag.
uint dn = dc_dim * dy_dim * dx_dim;
uint sn = sc_dim * sy_dim * sx_dim;
}
I can make typing even laggier by wrapping foo in foo, like this:
void foo(...) {
...
void foo(uint dc_dim, uint sc_dim,
uint fy_dim, uint fx_dim,
__global float * restrict F,
uint sy_dim, uint sx_dim,
__global float * restrict S,
uint padding,
__global float * restrict D) {
uint dy_dim = sy_dim + 2 * padding - fy_dim + 1;
uint dx_dim = sx_dim + 2 * padding - fx_dim + 1;
// Place cursor at d[y]_dim. Hold "y". Observe lag in c-mode.
uint dn = dc_dim * dy_dim * dx_dim;
uint sn = sc_dim * sy_dim * sx_dim;
}
}
The more times I wrap foo the slower c-mode gets. So if you have a
fast computer try nesting foo in foo 50 times... I have observed the
same annoying input lag on multiple computers and I don't use any
special c-mode configuration.
Please cc me as I'm not subscribed to the list.
GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43,
cairo version 1.18.2)
--
mvh/best regards Björn Lindqvist
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag
2024-11-14 20:39 bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag Björn Lindqvist
@ 2024-11-15 7:40 ` Eli Zaretskii
2024-11-15 14:08 ` Björn Lindqvist
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-11-15 7:40 UTC (permalink / raw)
To: Björn Lindqvist, Alan Mackenzie; +Cc: 74357
> From: Björn Lindqvist <bjourne@gmail.com>
> Date: Thu, 14 Nov 2024 21:39:53 +0100
>
> This bug has been present in c-mode for at least a year, but I haven't
> gotten around to report it. The reason is that bugs about latency are
> erratic and tricky to triage. Typing when the cursor is on some
> syntatic constructs in c-mode causes severe lag on the order of several
> hundred milliseconds on my (admittedly slow) laptop. The lag
> makes c-mode almost unusable. Here is an MWE:
>
> void foo(uint dc_dim, uint sc_dim,
> uint fy_dim, uint fx_dim,
> __global const float * restrict F,
> uint sy_dim, uint sx_dim,
> __global const float * restrict S,
> uint padding,
> __global float * restrict D) {
> uint dy_dim = sy_dim + 2 * padding - fy_dim + 1;
> uint dx_dim = sx_dim + 2 * padding - fx_dim + 1;
>
> // Place cursor at "y" in "dy_dim". Hold "y" and observe lag.
> uint dn = dc_dim * dy_dim * dx_dim;
> uint sn = sc_dim * sy_dim * sx_dim;
> }
>
> I can make typing even laggier by wrapping foo in foo, like this:
>
> void foo(...) {
> ...
> void foo(uint dc_dim, uint sc_dim,
> uint fy_dim, uint fx_dim,
> __global float * restrict F,
> uint sy_dim, uint sx_dim,
> __global float * restrict S,
> uint padding,
> __global float * restrict D) {
> uint dy_dim = sy_dim + 2 * padding - fy_dim + 1;
> uint dx_dim = sx_dim + 2 * padding - fx_dim + 1;
>
> // Place cursor at d[y]_dim. Hold "y". Observe lag in c-mode.
> uint dn = dc_dim * dy_dim * dx_dim;
> uint sn = sc_dim * sy_dim * sx_dim;
> }
> }
>
> The more times I wrap foo the slower c-mode gets. So if you have a
> fast computer try nesting foo in foo 50 times... I have observed the
> same annoying input lag on multiple computers and I don't use any
> special c-mode configuration.
I've wrapped the snippet with 50 foo, and I still don't see any
significant lags.
Does it matter where you type, for reproducing the lag?
Also, can you run this under a profiler (M-x profiler-start) and then
show the full expanded profile produced by "M-x profiler-report" after
several tens of seconds of typing with the lag?
Adding Alan to the discussion.
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag
2024-11-15 7:40 ` Eli Zaretskii
@ 2024-11-15 14:08 ` Björn Lindqvist
2024-11-15 14:25 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Björn Lindqvist @ 2024-11-15 14:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alan Mackenzie, 74357
> > From: Björn Lindqvist <bjourne@gmail.com>
> > Date: Thu, 14 Nov 2024 21:39:53 +0100
> >
> > This bug has been present in c-mode for at least a year, but I haven't
> > gotten around to report it. The reason is that bugs about latency are
> > erratic and tricky to triage. Typing when the cursor is on some
> > syntatic constructs in c-mode causes severe lag on the order of several
> > hundred milliseconds on my (admittedly slow) laptop. The lag
> > makes c-mode almost unusable. Here is an MWE:
> >
> > void foo(uint dc_dim, uint sc_dim,
> > uint fy_dim, uint fx_dim,
> > __global const float * restrict F,
> > uint sy_dim, uint sx_dim,
> > __global const float * restrict S,
> > uint padding,
> > __global float * restrict D) {
> > uint dy_dim = sy_dim + 2 * padding - fy_dim + 1;
> > uint dx_dim = sx_dim + 2 * padding - fx_dim + 1;
> >
> > // Place cursor at "y" in "dy_dim". Hold "y" and observe lag.
> > uint dn = dc_dim * dy_dim * dx_dim;
> > uint sn = sc_dim * sy_dim * sx_dim;
> > }
> >
> > I can make typing even laggier by wrapping foo in foo, like this:
> >
> > void foo(...) {
> > ...
> > void foo(uint dc_dim, uint sc_dim,
> > uint fy_dim, uint fx_dim,
> > __global float * restrict F,
> > uint sy_dim, uint sx_dim,
> > __global float * restrict S,
> > uint padding,
> > __global float * restrict D) {
> > uint dy_dim = sy_dim + 2 * padding - fy_dim + 1;
> > uint dx_dim = sx_dim + 2 * padding - fx_dim + 1;
> >
> > // Place cursor at d[y]_dim. Hold "y". Observe lag in c-mode.
> > uint dn = dc_dim * dy_dim * dx_dim;
> > uint sn = sc_dim * sy_dim * sx_dim;
> > }
> > }
> >
> > The more times I wrap foo the slower c-mode gets. So if you have a
> > fast computer try nesting foo in foo 50 times... I have observed the
> > same annoying input lag on multiple computers and I don't use any
> > special c-mode configuration.
>
> I've wrapped the snippet with 50 foo, and I still don't see any
> significant lags.
>
> Does it matter where you type, for reproducing the lag?
>
> Also, can you run this under a profiler (M-x profiler-start) and then
> show the full expanded profile produced by "M-x profiler-report" after
> several tens of seconds of typing with the lag?
>
> Adding Alan to the discussion.
Hello Eli, thanks for the swift reply.
I've created a much larger example so you can see what I mean with
"wrapping foo in foo":
https://gist.github.com/bjourne/8f705c5879aa966accf354008623f6bb
Open file in c-mode, Go to line 328, place the cursor on "y" in "dy_dim"
and press and hold "y". Unless you have a supercomputer the lag will be
really apparent. Disable Global Font-lock mode and repeat the exercise.
Lag will be gone. Lag is worse if I use non-jitted Emacs, but really
apparent in jitted Emacs too. Lag goes away if I use c-ts-mode instead
of c-mode.
I want to emphasize that lag is present in normal code too, but easier
to detect in these specially crafted samples.
My system-configuration-features:
"ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3
ZLIB"
Profiler report:
https://gist.github.com/bjourne/842695100e99c8fd6ef87fcdd0a6ed0b
--
mvh/best regards Björn Lindqvist
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag
2024-11-15 14:08 ` Björn Lindqvist
@ 2024-11-15 14:25 ` Eli Zaretskii
2024-11-15 14:45 ` Alan Mackenzie
2024-11-15 21:43 ` Björn Lindqvist
0 siblings, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2024-11-15 14:25 UTC (permalink / raw)
To: Björn Lindqvist; +Cc: acm, 74357
> From: Björn Lindqvist <bjourne@gmail.com>
> Date: Fri, 15 Nov 2024 15:08:09 +0100
> Cc: Alan Mackenzie <acm@muc.de>, 74357@debbugs.gnu.org
>
> > I've wrapped the snippet with 50 foo, and I still don't see any
> > significant lags.
> >
> > Does it matter where you type, for reproducing the lag?
> >
> > Also, can you run this under a profiler (M-x profiler-start) and then
> > show the full expanded profile produced by "M-x profiler-report" after
> > several tens of seconds of typing with the lag?
> >
> > Adding Alan to the discussion.
>
> Hello Eli, thanks for the swift reply.
>
>
> I've created a much larger example so you can see what I mean with
> "wrapping foo in foo":
>
> https://gist.github.com/bjourne/8f705c5879aa966accf354008623f6bb
>
> Open file in c-mode, Go to line 328, place the cursor on "y" in "dy_dim"
> and press and hold "y". Unless you have a supercomputer the lag will be
> really apparent. Disable Global Font-lock mode and repeat the exercise.
> Lag will be gone. Lag is worse if I use non-jitted Emacs, but really
> apparent in jitted Emacs too. Lag goes away if I use c-ts-mode instead
> of c-mode.
Yes, I see the lag now, thanks; the profile is below. I'll let Alan
look into this and see how this can be improved.
> I want to emphasize that lag is present in normal code too, but easier
> to detect in these specially crafted samples.
Can you tell where in real life do you see such deeply-nested braces
in C source files?
Here's the profile I collected:
622 60% - redisplay_internal (C function)
615 59% - jit-lock-function
615 59% - jit-lock-fontify-now
614 59% - jit-lock--run-functions
614 59% - run-hook-wrapped
614 59% - #<byte-code-function 550>
614 59% - font-lock-fontify-region
614 59% - c-font-lock-fontify-region
582 56% - font-lock-default-fontify-region
581 56% - font-lock-fontify-keywords-region
323 31% - c-font-lock-cut-off-declarators
302 29% - c-get-fontification-context
301 29% - c-inside-bracelist-p
221 21% - c-looking-at-or-maybe-in-bracelist
154 14% - c-laomib-loop
69 6% - c-backward-sws
23 2% - c-beginning-of-macro
5 0% - back-to-indentation
2 0% skip-syntax-forward
1 0% line-end-position
1 0% backward-prefix-chars
4 0% beginning-of-line
3 0% looking-at
3 0% re-search-forward
2 0% line-end-position
2 0% match-data
1 0% #<byte-code-function 76C>
1 0% - #<byte-code-function 722>
1 0% set-match-data
1 0% make-closure
11 1% looking-at
7 0% skip-syntax-backward
5 0% - c-beginning-of-current-token
2 0% skip-syntax-backward
2 0% looking-at
5 0% forward-comment
3 0% skip-syntax-forward
1 0% make-closure
1 0% buffer-modified-p
50 4% - c-backward-token-2
41 3% - c-backward-sws
11 1% - c-beginning-of-macro
3 0% beginning-of-line
2 0% re-search-forward
2 0% - back-to-indentation
2 0% line-end-position
2 0% looking-at
1 0% - #<byte-code-function BFC>
1 0% set-match-data
7 0% looking-at
2 0% forward-comment
2 0% skip-syntax-backward
2 0% - c-beginning-of-current-token
2 0% skip-syntax-backward
1 0% buffer-modified-p
1 0% skip-syntax-forward
1 0% text-property-any
5 0% looking-at
1 0% scan-sexps
31 3% - c-at-macro-vsemi-p
13 1% looking-at
9 0% - c-backward-sws
7 0% looking-at
2 0% - c-beginning-of-current-token
1 0% looking-at
1 0% skip-syntax-backward
4 0% skip-syntax-backward
2 0% looking-at
53 5% - c-backward-token-2
49 4% scan-sexps
2 0% looking-at
1 0% - c-backward-sws
1 0% looking-at
12 1% - c-backward-sws
3 0% - c-beginning-of-macro
1 0% - back-to-indentation
1 0% skip-syntax-forward
1 0% looking-at
3 0% looking-at
1 0% forward-comment
1 0% skip-syntax-backward
1 0% skip-syntax-forward
1 0% c-laomib-get-cache
1 0% - c-back-over-compound-identifier
1 0% c-on-identifier
79 7% - c-looking-at-inexpr-block
38 3% scan-sexps
31 3% - c-backward-sws
12 1% - c-beginning-of-macro
2 0% - back-to-indentation
1 0% line-end-position
1 0% skip-syntax-forward
1 0% re-search-forward
1 0% make-closure
1 0% - #<byte-code-function 4CA>
1 0% set-match-data
1 0% looking-at
1 0% match-data
7 0% looking-at
3 0% skip-syntax-backward
2 0% - c-beginning-of-current-token
2 0% looking-at
2 0% forward-comment
10 0% looking-at
1 0% - c-backward-over-enum-header
1 0% scan-lists
1 0% - c-parse-state
1 0% - c-parse-state-1
1 0% - c-remove-stale-state-cache
1 0% - c-beginning-of-macro
1 0% re-search-forward
7 0% - c-determine-limit
4 0% parse-partial-sexp
3 0% - c-semi-pp-to-literal
3 0% parse-partial-sexp
6 0% - c-forward-decl-or-cast-1
3 0% - c-forward-type
2 0% - c-forward-name
2 0% - c-determine-+ve-limit
2 0% parse-partial-sexp
1 0% - c-forward-keyword-clause
1 0% - c-forward-sws
1 0% looking-at
1 0% scan-sexps
4 0% - c-font-lock-single-decl
4 0% - c-font-lock-declarators
4 0% - c-do-declarators
3 0% - c-forward-declarator
2 0% - c-forward-name
2 0% - c-determine-+ve-limit
2 0% parse-partial-sexp
1 0% - c-forward-decl-arglist
1 0% scan-lists
1 0% - c-syntactic-re-search-forward
1 0% re-search-forward
2 0% - c-back-over-member-initializers
1 0% - c-backward-sws
1 0% skip-syntax-backward
1 0% - c-parse-state
1 0% - c-parse-state-1
1 0% - c-remove-stale-state-cache
1 0% - c-beginning-of-macro
1 0% looking-at
2 0% - c-at-toplevel-p
1 0% - c-search-uplist-for-classkey
1 0% - c-looking-at-decl-block
1 0% scan-lists
1 0% - c-parse-state
1 0% - c-parse-state-1
1 0% c-append-to-state-cache
226 21% - c-font-lock-declarations
226 21% - c-find-decl-spots
221 21% - #<byte-code-function 228>
170 16% - c-get-fontification-context
166 16% - c-inside-bracelist-p
108 10% - c-looking-at-or-maybe-in-bracelist
69 6% - c-laomib-loop
41 3% - c-backward-sws
11 1% looking-at
8 0% forward-comment
6 0% - c-beginning-of-macro
1 0% beginning-of-line
1 0% - back-to-indentation
1 0% line-end-position
1 0% re-search-forward
3 0% - c-beginning-of-current-token
2 0% skip-syntax-backward
1 0% looking-at
2 0% skip-syntax-backward
2 0% skip-syntax-forward
1 0% text-property-any
21 2% - c-backward-token-2
16 1% - c-backward-sws
4 0% - c-beginning-of-macro
2 0% - back-to-indentation
1 0% line-end-position
1 0% skip-syntax-forward
1 0% re-search-forward
1 0% - #<byte-code-function 75C>
1 0% set-match-data
3 0% skip-syntax-backward
2 0% looking-at
1 0% - c-beginning-of-current-token
1 0% looking-at
2 0% scan-sexps
6 0% - c-at-macro-vsemi-p
3 0% - c-backward-sws
2 0% looking-at
1 0% - c-beginning-of-current-token
1 0% looking-at
2 0% looking-at
1 0% looking-at
29 2% - c-backward-token-2
26 2% scan-sexps
2 0% looking-at
1 0% - c-backward-sws
1 0% looking-at
8 0% - c-backward-sws
3 0% skip-syntax-backward
2 0% looking-at
1 0% forward-comment
1 0% - c-beginning-of-macro
1 0% match-data
1 0% c-laomib-get-cache
55 5% - c-looking-at-inexpr-block
30 2% scan-sexps
16 1% - c-backward-sws
6 0% - c-beginning-of-macro
2 0% match-data
1 0% - back-to-indentation
1 0% line-end-position
1 0% beginning-of-line
5 0% looking-at
1 0% - c-beginning-of-current-token
1 0% skip-syntax-backward
1 0% skip-syntax-backward
1 0% #<byte-code-function FF6>
7 0% looking-at
2 0% - c-backward-over-enum-header
2 0% scan-lists
3 0% - c-parse-state
2 0% - c-parse-state-1
2 0% - c-remove-stale-state-cache
2 0% - c-beginning-of-macro
2 0% - back-to-indentation
2 0% backward-prefix-chars
1 0% - c-beginning-of-macro
1 0% - back-to-indentation
1 0% backward-prefix-chars
43 4% - c-forward-decl-or-cast-1
35 3% - c-forward-type
21 2% - c-forward-name
18 1% - c-determine-+ve-limit
16 1% parse-partial-sexp
1 0% skip-syntax-backward
1 0% looking-at
5 0% looking-at
5 0% - c-forward-sws
3 0% looking-at
2 0% - c-check-qualified-type
2 0% - c-forward-over-compound-identifier
2 0% - c-forward-over-token
2 0% - c-forward-sws
2 0% looking-at
1 0% - c-add-type
1 0% - c-add-type-1
1 0% - c-syntactic-content
1 0% re-search-forward
5 0% - c-forward-name
5 0% - c-determine-+ve-limit
5 0% parse-partial-sexp
3 0% looking-at
6 0% - c-font-lock-single-decl
6 0% - c-font-lock-declarators
6 0% - c-do-declarators
6 0% - c-forward-declarator
3 0% - c-forward-name
1 0% - c-determine-+ve-limit
1 0% parse-partial-sexp
1 0% - c-forward-sws
1 0% looking-at
1 0% looking-at
2 0% c-syntactic-re-search-forward
1 0% looking-at
1 0% looking-at
1 0% - c-backward-sws
1 0% text-property-any
5 0% - c-bs-at-toplevel-p
5 0% - c-brace-stack-at
5 0% - c-update-brace-stack
5 0% - c-syntactic-re-search-forward
3 0% parse-partial-sexp
2 0% - c-beginning-of-macro
1 0% make-closure
1 0% - back-to-indentation
1 0% beginning-of-line
27 2% - c-font-lock-enclosing-decls
12 1% - c-syntactic-skip-backward
5 0% - c-beginning-of-macro
3 0% - back-to-indentation
2 0% line-end-position
1 0% backward-prefix-chars
1 0% looking-at
1 0% line-end-position
4 0% - c-literal-start
4 0% - c-semi-pp-to-literal
4 0% parse-partial-sexp
2 0% - c-backward-sws
2 0% skip-syntax-backward
7 0% - c-forward-sws
6 0% looking-at
5 0% - c-determine-limit
5 0% parse-partial-sexp
2 0% looking-at
1 0% - c-parse-state
1 0% - c-parse-state-1
1 0% - c-append-to-state-cache
1 0% scan-lists
3 0% - c-font-lock-enum-tail
2 0% - c-parse-state
2 0% - c-parse-state-1
2 0% - c-append-to-state-cache
1 0% - c-beginning-of-macro
1 0% - #<byte-code-function 2B4>
1 0% set-match-data
1 0% scan-lists
1 0% - c-backward-over-enum-header
1 0% scan-lists
2 0% - c-font-lock-complex-decl-prepare
2 0% c-backward-sws
1 0% - font-lock-fontify-syntactically-region
1 0% - font-lock-default-fontify-syntactically
1 0% - syntax-ppss
1 0% parse-partial-sexp
32 3% - c-before-context-fl-expand-region
32 3% - mapc
32 3% - #<byte-code-function 364>
32 3% - c-context-expand-fl-region
16 1% - c-fl-decl-end
13 1% - c-determine-limit
11 1% - c-semi-pp-to-literal
10 0% parse-partial-sexp
1 0% looking-at
1 0% parse-partial-sexp
1 0% - c-determine-limit-no-macro
1 0% - c-beginning-of-macro
1 0% beginning-of-line
2 0% - c-forward-declarator
1 0% - c-forward-name
1 0% - c-determine-+ve-limit
1 0% parse-partial-sexp
1 0% - c-syntactic-re-search-forward
1 0% - c-beginning-of-macro
1 0% beginning-of-line
1 0% - c-backward-sws
1 0% - c-beginning-of-current-token
1 0% looking-at
16 1% - c-fl-decl-start
5 0% - c-forward-type
4 0% - c-forward-name
2 0% - c-determine-+ve-limit
2 0% parse-partial-sexp
1 0% looking-at
1 0% - c-forward-sws
1 0% looking-at
1 0% looking-at
4 0% - c-determine-limit
4 0% parse-partial-sexp
2 0% - c-syntactic-skip-backward
1 0% - c-literal-start
1 0% - c-semi-pp-to-literal
1 0% parse-partial-sexp
1 0% - c-beginning-of-macro
1 0% - back-to-indentation
1 0% line-end-position
2 0% - c-looking-at-or-maybe-in-bracelist
2 0% - c-backward-token-2
2 0% scan-sexps
2 0% - c-literal-start
2 0% - c-semi-pp-to-literal
2 0% parse-partial-sexp
1 0% - c-parse-state
1 0% - c-parse-state-1
1 0% - c-remove-stale-state-cache-backwards
1 0% - c-state-literal-at
1 0% - c-state-pp-to-literal
1 0% parse-partial-sexp
387 37% Automatic GC
13 1% - command-execute
13 1% - call-interactively
10 0% - funcall-interactively
5 0% - self-insert-command
3 0% - c-after-change
3 0% - mapc
3 0% - #<byte-code-function B02>
3 0% - c-change-expand-fl-region
3 0% - c-fl-decl-end
1 0% c-backward-sws
1 0% - c-forward-declarator
1 0% - c-forward-name
1 0% - c-forward-sws
1 0% looking-at
2 0% - c-before-change
1 0% - c-determine-limit
1 0% parse-partial-sexp
1 0% - c-invalidate-sws-region-before
1 0% - c-literal-limits
1 0% c-full-pp-to-literal
5 0% - next-line
5 0% - line-move
5 0% - line-move-partial
5 0% - pos-visible-in-window-p
4 0% - jit-lock-function
4 0% - jit-lock-fontify-now
4 0% - jit-lock--run-functions
4 0% - run-hook-wrapped
4 0% - #<byte-code-function 9C0>
4 0% - font-lock-fontify-region
4 0% - c-font-lock-fontify-region
3 0% - font-lock-default-fontify-region
3 0% - font-lock-fontify-keywords-region
2 0% - c-font-lock-cut-off-declarators
2 0% - c-get-fontification-context
2 0% - c-inside-bracelist-p
1 0% - c-looking-at-or-maybe-in-bracelist
1 0% c-laomib-loop
1 0% - c-looking-at-inexpr-block
1 0% scan-sexps
1 0% - c-font-lock-declarations
1 0% - c-find-decl-spots
1 0% - #<byte-code-function DC4>
1 0% - c-forward-decl-or-cast-1
1 0% looking-at
1 0% - c-before-context-fl-expand-region
1 0% - mapc
1 0% - #<byte-code-function E22>
1 0% - c-context-expand-fl-region
1 0% - c-fl-decl-end
1 0% - c-determine-limit
1 0% - c-semi-pp-to-literal
1 0% parse-partial-sexp
3 0% - byte-code
3 0% - read-extended-command
3 0% - read-extended-command-1
3 0% - completing-read
3 0% - completing-read-default
3 0% - read-from-minibuffer
1 0% redisplay_internal (C function)
7 0% - timer-event-handler
7 0% - apply
6 0% - c-force-redisplay
6 0% - c-font-lock-fontify-region
5 0% - font-lock-default-fontify-region
4 0% - font-lock-fontify-keywords-region
2 0% - c-font-lock-declarations
2 0% - c-find-decl-spots
2 0% - c-bs-at-toplevel-p
2 0% - c-brace-stack-at
2 0% - c-update-brace-stack
2 0% - c-syntactic-re-search-forward
2 0% parse-partial-sexp
1 0% - c-font-lock-enclosing-decls
1 0% - c-syntactic-skip-backward
1 0% - c-literal-start
1 0% - c-semi-pp-to-literal
1 0% parse-partial-sexp
1 0% re-search-forward
1 0% - font-lock-fontify-syntactically-region
1 0% - font-lock-default-fontify-syntactically
1 0% - syntax-ppss
1 0% parse-partial-sexp
1 0% - c-before-context-fl-expand-region
1 0% - mapc
1 0% - #<byte-code-function FA0>
1 0% - c-context-expand-fl-region
1 0% - c-fl-decl-end
1 0% - c-determine-limit
1 0% - c-semi-pp-to-literal
1 0% parse-partial-sexp
1 0% - #<byte-code-function 88A>
1 0% - completion--in-region-1
1 0% - completion--do-completion
1 0% - completion-try-completion
1 0% - completion--nth-completion
1 0% - seq-some
1 0% - seq-do
1 0% - mapc
1 0% - #<byte-code-function 35C>
1 0% - #<byte-code-function 008>
1 0% - completion-basic-try-completion
1 0% - try-completion
1 0% - #<byte-code-function 704>
1 0% - complete-with-action
1 0% try-completion
0 0% ...
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag
2024-11-15 14:25 ` Eli Zaretskii
@ 2024-11-15 14:45 ` Alan Mackenzie
2024-11-15 21:43 ` Björn Lindqvist
1 sibling, 0 replies; 7+ messages in thread
From: Alan Mackenzie @ 2024-11-15 14:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, Björn Lindqvist, 74357
Hello, Eli and Björn.
On Fri, Nov 15, 2024 at 16:25:39 +0200, Eli Zaretskii wrote:
> > From: Björn Lindqvist <bjourne@gmail.com>
> > Date: Fri, 15 Nov 2024 15:08:09 +0100
> > Cc: Alan Mackenzie <acm@muc.de>, 74357@debbugs.gnu.org
> > > I've wrapped the snippet with 50 foo, and I still don't see any
> > > significant lags.
> > > Does it matter where you type, for reproducing the lag?
> > > Also, can you run this under a profiler (M-x profiler-start) and then
> > > show the full expanded profile produced by "M-x profiler-report" after
> > > several tens of seconds of typing with the lag?
> > > Adding Alan to the discussion.
> > Hello Eli, thanks for the swift reply.
> > I've created a much larger example so you can see what I mean with
> > "wrapping foo in foo":
> > https://gist.github.com/bjourne/8f705c5879aa966accf354008623f6bb
> > Open file in c-mode, Go to line 328, place the cursor on "y" in "dy_dim"
> > and press and hold "y". Unless you have a supercomputer the lag will be
> > really apparent. Disable Global Font-lock mode and repeat the exercise.
> > Lag will be gone. Lag is worse if I use non-jitted Emacs, but really
> > apparent in jitted Emacs too. Lag goes away if I use c-ts-mode instead
> > of c-mode.
> Yes, I see the lag now, thanks; the profile is below. I'll let Alan
> look into this and see how this can be improved.
Thanks, Eli! I'll look into this.
> > I want to emphasize that lag is present in normal code too, but easier
> > to detect in these specially crafted samples.
> Can you tell where in real life do you see such deeply-nested braces
> in C source files?
> Here's the profile I collected:
[ .... ]
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag
2024-11-15 14:25 ` Eli Zaretskii
2024-11-15 14:45 ` Alan Mackenzie
@ 2024-11-15 21:43 ` Björn Lindqvist
2024-11-16 11:00 ` Eli Zaretskii
1 sibling, 1 reply; 7+ messages in thread
From: Björn Lindqvist @ 2024-11-15 21:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, 74357
Den fre 15 nov. 2024 kl 15:25 skrev Eli Zaretskii <eliz@gnu.org>:
> Can you tell where in real life do you see such deeply-nested braces
> in C source files?
50 is perhaps exaggerating it, but in "modern" C++ with multiple
namespaces, nested classes, and anonymous functions you can easily get
scopes nested over a dozen levels deep.
--
mvh/best regards Björn Lindqvist
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag
2024-11-15 21:43 ` Björn Lindqvist
@ 2024-11-16 11:00 ` Eli Zaretskii
0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2024-11-16 11:00 UTC (permalink / raw)
To: Björn Lindqvist; +Cc: acm, 74357
> From: Björn Lindqvist <bjourne@gmail.com>
> Date: Fri, 15 Nov 2024 22:43:45 +0100
> Cc: acm@muc.de, 74357@debbugs.gnu.org
>
> Den fre 15 nov. 2024 kl 15:25 skrev Eli Zaretskii <eliz@gnu.org>:
> > Can you tell where in real life do you see such deeply-nested braces
> > in C source files?
>
> 50 is perhaps exaggerating it, but in "modern" C++ with multiple
> namespaces, nested classes, and anonymous functions you can easily get
> scopes nested over a dozen levels deep.
Can you show such a file from a real-life project? I'd like us to
have it as a means for judging real-life performance in these cases.
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-11-16 11:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-14 20:39 bug#74357: c-mode: Some syntactic constructs cause unreasonable typing lag Björn Lindqvist
2024-11-15 7:40 ` Eli Zaretskii
2024-11-15 14:08 ` Björn Lindqvist
2024-11-15 14:25 ` Eli Zaretskii
2024-11-15 14:45 ` Alan Mackenzie
2024-11-15 21:43 ` Björn Lindqvist
2024-11-16 11:00 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.