* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
@ 2020-09-26 11:17 Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-26 11:41 ` Eli Zaretskii
2023-10-13 15:26 ` Alan Mackenzie
0 siblings, 2 replies; 12+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-09-26 11:17 UTC (permalink / raw)
To: 43631
Hello there!
While creating a new mode derived from CC Mode, we noticed performance
is affected heavily when setting a character for
'c-multiline-string-start-char'. There is a discussion around this that
can be found at https://github.com/josteink/csharp-mode/issues/164,
and we were given an easily reproducible repo for this. It is verified
to slow typing down both in 'csharp-mode', 'pike-mode' and in this test
case:
https://github.com/unhammer/csharp-mode/tree/164-repro
I think (unconvincingly) that some of the problematic code is situated
around line 2047 in 'cc-mode.el', but this is only a guess taken from
some light profiling.
The issue is described well on github, and I think me trying to
reiterate that here will only cause subtle confusions.
One thing of note is that you don't even have to have any multiline
strings for this performance hit to occur, meaning all 'csharp-mode'
files do suffer from this.
Let me know if something is still unclear, and I'll try to bring up some
more information.
All the best,
Theodor Thornhill
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 11:17 bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2020-09-26 11:41 ` Eli Zaretskii
2020-09-26 12:40 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-13 15:26 ` Alan Mackenzie
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2020-09-26 11:41 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: 43631
> Date: Sat, 26 Sep 2020 13:17:29 +0200
> From: Theodor Thornhill via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> While creating a new mode derived from CC Mode, we noticed performance
> is affected heavily when setting a character for
> 'c-multiline-string-start-char'. There is a discussion around this that
> can be found at https://github.com/josteink/csharp-mode/issues/164,
> and we were given an easily reproducible repo for this. It is verified
> to slow typing down both in 'csharp-mode', 'pike-mode' and in this test
> case:
> https://github.com/unhammer/csharp-mode/tree/164-repro
>
> I think (unconvincingly) that some of the problematic code is situated
> around line 2047 in 'cc-mode.el', but this is only a guess taken from
> some light profiling.
All the profiles posted there end prematurely, thus making it
impossible to make independent conclusions regarding the possible
culprits. Would it be possible to post here a full profile,
completely expanded, obtained after loading all the relevant *.el
files as *.el (NOT *.elc!), so that the profile is detailed enough to
show the relevant parts? It would make the discussion much more
focused.
Bonus points for posting another profile, where the feature you think
is the main culprit is disabled.
TIA
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 11:41 ` Eli Zaretskii
@ 2020-09-26 12:40 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-26 13:43 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-09-26 12:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43631
[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> All the profiles posted there end prematurely, thus making it
> impossible to make independent conclusions regarding the possible
> culprits. Would it be possible to post here a full profile,
> completely expanded, obtained after loading all the relevant *.el
> files as *.el (NOT *.elc!), so that the profile is detailed enough to
> show the relevant parts? It would make the discussion much more
> focused.
>
> Bonus points for posting another profile, where the feature you think
> is the main culprit is disabled.
>
> TIA
Attached is two reports, one which is super slow, and one that is fast.
Recipe:
- git clone https://github.com/unhammer/csharp-mode/
- git checkout 164-repro
- eval csharp-mode.el
- open superslow.cs and write some text
- rinse, repeat, but with
(c-lang-defconst c-multiline-string-start-char
csharp ?@)
commented out.
One is unbearably slow, the other is super fast.
Hope this helps a little!
All the best,
Theodor Thornhill
[-- Attachment #2: not-slow-without-multiline.txt --]
[-- Type: text/plain, Size: 1648 bytes --]
[profiler-profile "24.3" cpu #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ([redisplay sit-for execute-extended-command funcall-interactively call-interactively command-execute nil nil nil nil nil nil nil nil nil nil] 1 [progn unwind-protect let and if save-restriction if progn if let c-beginning-of-macro and let* progn unwind-protect let*] 1 [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil] 17 [font-lock-fontify-syntactically-region font-lock-default-fontify-region funcall progn unwind-protect let* progn unwind-protect let* let save-restriction c-font-lock-fontify-region font-lock-fontify-region "#<compiled 0x58b8bcdf3863eb5>" run-hook-wrapped jit-lock--run-functions] 1 [progn cond let* save-excursion progn unwind-protect let c-invalidate-sws-region-before save-excursion progn unwind-protect progn unwind-protect let save-restriction if] 1 [self-insert-command funcall-interactively call-interactively command-execute nil nil nil nil nil nil nil nil nil nil nil nil] 1 [save-restriction progn if c-extend-after-change-region font-lock-extend-jit-lock-region-after-change run-hook-with-args jit-lock-after-change self-insert-command funcall-interactively call-interactively command-execute nil nil nil nil nil] 1 [read-from-minibuffer completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil nil nil nil nil] 2 [completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil nil nil nil nil nil] 2 [Automatic\ GC] 11)) (24431 13788 861111 419000) nil]
[-- Attachment #3: report-slow-with-multiline.txt --]
[-- Type: text/plain, Size: 6146 bytes --]
[profiler-profile "24.3" cpu #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ([sit-for execute-extended-command funcall-interactively call-interactively command-execute nil nil nil nil nil nil nil nil nil nil nil] 1 [progn while let* c-pps-to-string-delim progn and while progn if cond let* progn unwind-protect let* c-before-change-check-unbalanced-strings funcall] 1212 [setq cond progn and while condition-case let c-syntactic-re-search-forward and while progn and while progn if cond] 1 [c-pps-to-string-delim progn and while progn if cond let* progn unwind-protect let* c-before-change-check-unbalanced-strings funcall "#<lambda 0x8f29c4b23d484>" mapc if] 2 [unwind-protect let save-excursion cond progn and while condition-case let c-syntactic-re-search-forward and while progn and while progn] 1 [remove-text-properties progn if while let c-clear-char-property-with-value-on-char-function progn if let* progn unwind-protect let* c-parse-quotes-before-change funcall "#<lambda 0x8f29c4b23d484>" mapc] 1 [progn while let* c-pps-to-string-delim cond let* progn unwind-protect let* c-before-change-check-unbalanced-strings funcall "#<lambda 0x8f29c4b23d484>" mapc if save-excursion progn] 3 [progn and while progn and while progn if cond let* progn unwind-protect let* c-before-change-check-unbalanced-strings funcall "#<lambda 0x8f29c4b23d484>"] 2 [setq progn and while condition-case let c-syntactic-re-search-forward and while progn and while progn if cond let*] 1 [progn and while condition-case let c-syntactic-re-search-forward and while progn and while progn if cond let* progn] 1 [setq while progn if let save-restriction save-excursion c-parse-ps-state-below setq progn if let* progn unwind-protect let save-restriction] 2 [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil] 2 [set-match-data unwind-protect let progn if save-restriction if progn if let c-beginning-of-macro progn unwind-protect let save-excursion cond] 1 [let if c-invalidate-state-cache-1 if c-invalidate-state-cache cond while save-restriction let* progn unwind-protect let* c-parse-quotes-after-change funcall "#<lambda 0xb9ab7fa2473f23>" mapc] 2 [if if while let* progn unwind-protect let* if c-after-change-mark-abnormal-strings funcall "#<lambda 0xb9ab7fa2473f23>" mapc save-excursion progn unwind-protect progn] 5 [goto-char let* c-pps-to-string-delim progn and while progn if cond let* progn unwind-protect let* c-before-change-check-unbalanced-strings funcall "#<lambda 0x8f29c4b23d484>"] 1 [if progn and while condition-case let c-syntactic-re-search-forward and while progn and while progn if cond let*] 4 [and if progn while progn unwind-protect let progn if save-restriction if progn if let c-beginning-of-macro progn] 2 [if progn if let c-beginning-of-macro progn unwind-protect let save-excursion cond progn and while condition-case let c-syntactic-re-search-forward] 2 [save-restriction if progn if let c-beginning-of-macro progn unwind-protect let save-excursion cond progn and while condition-case let] 2 [let and if save-restriction if progn if let c-beginning-of-macro progn unwind-protect let save-excursion cond progn and] 2 [cond progn and while condition-case let c-syntactic-re-search-forward and while progn and while progn if cond let*] 1 [and if let c-backward-sws c-determine-limit-get-base let* save-excursion c-determine-limit setq if let c-fl-decl-start or setq if c-change-expand-fl-region] 1 [let* c-pps-to-string-delim progn and while progn if cond let* progn unwind-protect let* c-before-change-check-unbalanced-strings funcall "#<lambda 0x8f29c4b23d484>" mapc] 1 [assq cdr looking-at if if while let* progn unwind-protect let* if c-after-change-mark-abnormal-strings funcall "#<lambda 0xb9ab7fa2473f23>" mapc save-excursion] 1 [let c-syntactic-re-search-forward and while progn and while progn if cond let* progn unwind-protect let* c-before-change-check-unbalanced-strings funcall] 1 [setq c-truncate-lit-pos-cache c-clear-syn-tab progn and while progn and while progn if cond let* progn unwind-protect let*] 1 [c-clear-syn-tab if progn while let* c-pps-to-string-delim progn and while progn if cond let* progn unwind-protect let*] 2 [char-before eq while progn while progn unwind-protect let progn if save-restriction if progn if let c-beginning-of-macro] 1 [c-syntactic-re-search-forward and while progn and while progn if cond let* progn unwind-protect let* c-before-change-check-unbalanced-strings funcall "#<lambda 0x8f29c4b23d484>"] 2 [setq c-truncate-lit-pos-cache c-invalidate-state-cache-1 if c-invalidate-state-cache cond while save-restriction let* progn unwind-protect let* c-parse-quotes-after-change funcall "#<lambda 0xb9ab7fa2473f23>" mapc] 1 [and while save-restriction let* progn unwind-protect let* c-parse-quotes-after-change funcall "#<lambda 0xb9ab7fa2473f23>" mapc save-excursion progn unwind-protect progn unwind-protect] 1 [not save-excursion cond while save-restriction let* progn unwind-protect let* c-parse-quotes-after-change funcall "#<lambda 0xb9ab7fa2473f23>" mapc save-excursion progn unwind-protect] 1 [setq progn while progn and while let* progn unwind-protect let* if c-after-change-mark-abnormal-strings funcall "#<lambda 0xb9ab7fa2473f23>" mapc save-excursion] 1 [c-truncate-lit-pos-cache c-invalidate-state-cache-1 if c-invalidate-state-cache cond while save-restriction let* progn unwind-protect let* c-parse-quotes-after-change funcall "#<lambda 0xb9ab7fa2473f23>" mapc save-excursion] 1 [save-excursion cond progn and while condition-case let c-syntactic-re-search-forward and while progn and while progn if cond] 1 [unwind-protect let and if save-restriction if progn if let c-beginning-of-macro progn unwind-protect let save-excursion cond progn] 1 [while let* progn unwind-protect let* if c-after-change-mark-abnormal-strings funcall "#<lambda 0xb9ab7fa2473f23>" mapc save-excursion progn unwind-protect progn unwind-protect let] 1 [completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil nil nil nil nil nil] 4 [Automatic\ GC] 73)) (24431 13704 63591 401000) nil]
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 12:40 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2020-09-26 13:43 ` Eli Zaretskii
2020-09-26 16:03 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2020-09-26 13:43 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: 43631
> From: Theodor Thornhill <theo@thornhill.no>
> Cc: 43631@debbugs.gnu.org
> Date: Sat, 26 Sep 2020 14:40:36 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > All the profiles posted there end prematurely, thus making it
> > impossible to make independent conclusions regarding the possible
> > culprits. Would it be possible to post here a full profile,
> > completely expanded, obtained after loading all the relevant *.el
> > files as *.el (NOT *.elc!), so that the profile is detailed enough to
> > show the relevant parts? It would make the discussion much more
> > focused.
> >
> > Bonus points for posting another profile, where the feature you think
> > is the main culprit is disabled.
> >
> > TIA
>
>
> Attached is two reports, one which is super slow, and one that is fast.
Thanks, but please post the text of Profiler-Report buffer, not the
internal structure it produces.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 13:43 ` Eli Zaretskii
@ 2020-09-26 16:03 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-26 16:17 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-09-26 16:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43631
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
[...]
>>
>> Attached is two reports, one which is super slow, and one that is fast.
>
> Thanks, but please post the text of Profiler-Report buffer, not the
> internal structure it produces.
Ok, third time's the charm:
recipe same as before.
Theodor Thornhill
[-- Attachment #2: fast-without-multiline.txt --]
[-- Type: text/plain, Size: 9094 bytes --]
- ... 16 84%
Automatic GC 7 36%
- #<compiled 0x58bf33e77bed1b5> 6 31%
- font-lock-fontify-region 6 31%
- c-font-lock-fontify-region 6 31%
- save-restriction 6 31%
- let 6 31%
- let* 6 31%
- unwind-protect 5 26%
- progn 5 26%
- let* 5 26%
- unwind-protect 5 26%
- progn 5 26%
- if 5 26%
- while 3 15%
- if 2 10%
- progn 2 10%
- cond 2 10%
- and 2 10%
- save-excursion 2 10%
- c-backward-sws 2 10%
- let 2 10%
- if 2 10%
- progn 2 10%
- let* 2 10%
- unwind-protect 2 10%
- progn 2 10%
- while 2 10%
- progn 2 10%
while 1 5%
- cond 1 5%
- and 1 5%
- c-beginning-of-macro 1 5%
- let 1 5%
- if 1 5%
- progn 1 5%
- if 1 5%
- save-restriction 1 5%
back-to-indentation 1 5%
- and 1 5%
- progn 1 5%
- and 1 5%
- or 1 5%
- and 1 5%
- save-excursion 1 5%
- consp 1 5%
- c-looking-at-or-maybe-in-bracelist 1 5%
- save-excursion 1 5%
- let 1 5%
- setq 1 5%
- c-backward-token-2 1 5%
- if 1 5%
let 1 5%
- setq 2 10%
- or 1 5%
- c-fl-decl-start 1 5%
- let 1 5%
- if 1 5%
- setq 1 5%
- c-determine-limit 1 5%
- save-excursion 1 5%
- let* 1 5%
- c-determine-limit-get-base 1 5%
- c-backward-sws 1 5%
- let 1 5%
- if 1 5%
- progn 1 5%
- let* 1 5%
unwind-protect 1 5%
- c-before-context-fl-expand-region 1 5%
- save-restriction 1 5%
save-excursion 1 5%
- c-literal-limits 1 5%
- save-excursion 1 5%
- let* 1 5%
- if 1 5%
- let* 1 5%
- c-full-pp-to-literal 1 5%
- save-excursion 1 5%
- save-restriction 1 5%
- let 1 5%
- unwind-protect 1 5%
- progn 1 5%
- let* 1 5%
- if 1 5%
- progn 1 5%
setq 1 5%
- minibuffer-complete 2 10%
- completion-in-region 2 10%
- completion--in-region 2 10%
- #<compiled -0x1c5315e0cd87232b> 2 10%
- apply 2 10%
- #<compiled -0x1e4d7dc09254ac50> 2 10%
- completion--in-region-1 2 10%
- completion--do-completion 2 10%
- completion-try-completion 2 10%
- completion--nth-completion 2 10%
- completion--some 2 10%
- #<compiled 0x1922efbe14fc19c1> 2 10%
- completion-basic-try-completion 2 10%
- try-completion 2 10%
- #<compiled 0x1b96ac9f54bd7d4> 2 10%
complete-with-action 2 10%
- self-insert-command 1 5%
- c-before-change 1 5%
- if 1 5%
- save-restriction 1 5%
- let 1 5%
- unwind-protect 1 5%
- progn 1 5%
- unwind-protect 1 5%
- progn 1 5%
- save-excursion 1 5%
- c-unfind-enclosing-token 1 5%
- save-excursion 1 5%
- let 1 5%
- progn 1 5%
- and 1 5%
c-end-of-current-token 1 5%
+ command-execute 2 10%
+ timer-event-handler 1 5%
[-- Attachment #3: slow-with-multiline.txt --]
[-- Type: text/plain, Size: 14603 bytes --]
- ... 1500 99%
- c-before-change 1420 94%
- if 1420 94%
- save-restriction 1420 94%
- let 1420 94%
- unwind-protect 1420 94%
- progn 1420 94%
- unwind-protect 1418 94%
- progn 1418 94%
- save-excursion 1418 94%
- if 1403 93%
- mapc 1403 93%
- #<lambda 0x893fa310e5384> 1403 93%
- funcall 1403 93%
- c-before-change-check-unbalanced-strings 1400 93%
- let* 1400 93%
- unwind-protect 1400 93%
- progn 1400 93%
- let* 1400 93%
- cond 1400 93%
- if 1398 93%
- progn 1398 93%
- while 1398 93%
- and 1398 93%
- progn 1398 93%
- c-pps-to-string-delim 1372 91%
- let* 1371 91%
- while 1367 90%
- progn 1366 90%
- if 4 0%
- c-clear-syn-tab 3 0%
let 1 0%
- cons 2 0%
- cons 2 0%
- cons 2 0%
- cons 1 0%
- cons 1 0%
- cons 1 0%
- cons 1 0%
cons 1 0%
- while 25 1%
- and 25 1%
- c-syntactic-re-search-forward 23 1%
- let 22 1%
- condition-case 22 1%
- while 22 1%
- and 22 1%
- progn 22 1%
- cond 16 1%
- save-excursion 15 0%
- let 15 0%
- unwind-protect 13 0%
- progn 13 0%
- c-beginning-of-macro 13 0%
- let 13 0%
- if 9 0%
- progn 9 0%
- if 9 0%
- save-restriction 8 0%
- if 6 0%
- progn 3 0%
- let 3 0%
- unwind-protect 3 0%
- progn 3 0%
- while 3 0%
- progn 3 0%
- if 3 0%
and 2 0%
- and 3 0%
- let 3 0%
- unwind-protect 1 0%
progn 1 0%
if 3 0%
setq 2 0%
- progn 2 0%
- c-clear-syn-tab 2 0%
- let 1 0%
setq 1 0%
memq 1 0%
- c-pps-to-string-delim 2 0%
- let* 2 0%
- while 2 0%
progn 2 0%
- c-parse-quotes-before-change 2 0%
- let* 2 0%
- unwind-protect 2 0%
- progn 2 0%
- let* 2 0%
- if 2 0%
- progn 2 0%
- c-clear-char-property-with-value-on-char-function 2 0%
- let 2 0%
- while 2 0%
- if 2 0%
progn 2 0%
- c-extend-region-for-CPP 1 0%
- if 1 0%
c-beginning-of-macro 1 0%
- mapc 15 0%
- #<lambda 0xbfd395bd336c23> 15 0%
- funcall 15 0%
- c-parse-quotes-after-change 9 0%
- let* 9 0%
- unwind-protect 9 0%
- progn 9 0%
- let* 9 0%
- save-restriction 9 0%
- while 9 0%
- cond 8 0%
- c-invalidate-state-cache 6 0%
- if 6 0%
- c-invalidate-state-cache-1 6 0%
- if 5 0%
- let 5 0%
save-excursion 3 0%
- setq 1 0%
- or 1 0%
- if 1 0%
and 1 0%
- c-truncate-lit-pos-cache 1 0%
setq 1 0%
let 1 0%
- c-after-change-mark-abnormal-strings 5 0%
- if 5 0%
- let* 4 0%
- unwind-protect 4 0%
- progn 4 0%
- let* 4 0%
- while 4 0%
- if 2 0%
- if 1 0%
- looking-at 1 0%
- cdr 1 0%
assq 1 0%
- and 2 0%
- progn 2 0%
- while 2 0%
- progn 2 0%
- setq 2 0%
parse-partial-sexp 1 0%
- setq 1 0%
- or 1 0%
- c-fl-decl-start 1 0%
- let 1 0%
- if 1 0%
- setq 1 0%
- c-determine-limit 1 0%
- save-excursion 1 0%
- let* 1 0%
- c-determine-limit-get-base 1 0%
- let* 1 0%
- c-semi-pp-to-literal 1 0%
- save-excursion 1 0%
- save-restriction 1 0%
let 1 0%
- c-neutralize-syntax-in-CPP 1 0%
- let* 1 0%
- unwind-protect 1 0%
- progn 1 0%
- let* 1 0%
- let 1 0%
- while 1 0%
and 1 0%
- let* 2 0%
- if 2 0%
- progn 2 0%
- setq 2 0%
- c-parse-ps-state-below 2 0%
- save-excursion 2 0%
- save-restriction 2 0%
- let 2 0%
- if 2 0%
- progn 2 0%
- while 2 0%
setq 2 0%
Automatic GC 79 5%
- c-backward-sws 1 0%
- let 1 0%
- if 1 0%
- progn 1 0%
- let* 1 0%
- unwind-protect 1 0%
- progn 1 0%
- while 1 0%
- progn 1 0%
- c-backward-comments 1 0%
- let 1 0%
- while 1 0%
- and 1 0%
- if 1 0%
- if 1 0%
and 1 0%
+ command-execute 3 0%
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 16:03 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2020-09-26 16:17 ` Eli Zaretskii
2020-09-26 19:43 ` Dmitry Gutov
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Eli Zaretskii @ 2020-09-26 16:17 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: 43631
> From: Theodor Thornhill <theo@thornhill.no>
> Cc: 43631@debbugs.gnu.org
> Date: Sat, 26 Sep 2020 18:03:10 +0200
>
> > Thanks, but please post the text of Profiler-Report buffer, not the
> > internal structure it produces.
>
> Ok, third time's the charm:
Thanks. This seems to indicate that this loop in
c-pps-to-string-delim is the culprit:
(while (progn
(parse-partial-sexp (point) end nil nil st-s 'syntax-table)
(unless (bobp)
(c-clear-syn-tab (1- (point))))
(setq st-pos (point))
(and (< (point) end)
(not (eq (char-before) ?\")))))
But I'm confused why the "fast" profile starts with
font-lock-fontify-region, whereas the "slow" profile doesn't have
font-lock-fontify-region anywhere...
Hopefully, Alan can take it from here.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 16:17 ` Eli Zaretskii
@ 2020-09-26 19:43 ` Dmitry Gutov
2020-09-27 9:54 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-27 11:34 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 0 replies; 12+ messages in thread
From: Dmitry Gutov @ 2020-09-26 19:43 UTC (permalink / raw)
To: Eli Zaretskii, Theodor Thornhill; +Cc: 43631
On 26.09.2020 19:17, Eli Zaretskii wrote:
> But I'm confused why the "fast" profile starts with
> font-lock-fontify-region, whereas the "slow" profile doesn't have
> font-lock-fontify-region anywhere...
Because CC Mode doesn't use syntax-propertize-function (most major modes
do, so we're used to seeing "slow" syntax analysis being done inside
font-lock-fontify-region because it calls s-p-f).
CC Mode applies syntax properties inside before/after-change-functions,
and the "slow" profile reflects that: c-before-change is featured
prominently.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 16:17 ` Eli Zaretskii
2020-09-26 19:43 ` Dmitry Gutov
@ 2020-09-27 9:54 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-27 11:34 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 0 replies; 12+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-09-27 9:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43631
Eli Zaretskii <eliz@gnu.org> writes:
[...]
>
> Thanks. This seems to indicate that this loop in
> c-pps-to-string-delim is the culprit:
>
> (while (progn
> (parse-partial-sexp (point) end nil nil st-s 'syntax-table)
> (unless (bobp)
> (c-clear-syn-tab (1- (point))))
> (setq st-pos (point))
> (and (< (point) end)
> (not (eq (char-before) ?\")))))
>
> But I'm confused why the "fast" profile starts with
> font-lock-fontify-region, whereas the "slow" profile doesn't have
> font-lock-fontify-region anywhere...
>
Thanks for digging into this. I can add one more thing that I see. When
this variable is set to some char, typing that character and then quote
mark would only insert one quote and fontify to end of buffer as a
string.
Example:
- type @" // (#") for pike-mode
- see whole buffer get fontified
- no extra quote mark is inserted to make a proper pair.
What I would expect:
- type @"
- see @""
- type normally inside quote marks.
I am not sure how this is related, if at all, but found it noticeable
enough to add to this discussion.
Also, if the 'multiline-string' variable is not set, typing @" would
behave as expected, with the pair being closed and nothing other than
string is fontified.
> Hopefully, Alan can take it from here.
Theo
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 16:17 ` Eli Zaretskii
2020-09-26 19:43 ` Dmitry Gutov
2020-09-27 9:54 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2020-09-27 11:34 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-28 19:33 ` Alan Mackenzie
2 siblings, 1 reply; 12+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-09-27 11:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 43631
Eli Zaretskii <eliz@gnu.org> writes:
[...]
> But I'm confused why the "fast" profile starts with
> font-lock-fontify-region, whereas the "slow" profile doesn't have
> font-lock-fontify-region anywhere...
I see that when I remove 'c-before-change-check-unbalanced-strings from
'c-get-state-before-change-functions' the performance degradation
ceases. I'm not sure what else is affected by that change, so not sure
if that can be counted as a fix as far as 'csharp-mode' is concerned.
Just wanted to let you know.
Theo
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-27 11:34 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2020-09-28 19:33 ` Alan Mackenzie
2020-09-28 19:41 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 12+ messages in thread
From: Alan Mackenzie @ 2020-09-28 19:33 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: 43631
Hello, Theo.
On Sun, Sep 27, 2020 at 13:34:32 +0200, Theodor Thornhill wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> [...]
> > But I'm confused why the "fast" profile starts with
> > font-lock-fontify-region, whereas the "slow" profile doesn't have
> > font-lock-fontify-region anywhere...
> I see that when I remove 'c-before-change-check-unbalanced-strings from
> 'c-get-state-before-change-functions' the performance degradation
> ceases. I'm not sure what else is affected by that change, so not sure
> if that can be counted as a fix as far as 'csharp-mode' is concerned.
I would strongly recommend you not to make such a change, at least not
without a good deal of matching changes elsewhere. ;-)
It seems the bit in c-b-c-check-unbalanced-strings dealing with
multiline strings was written on the assumption that buffers containing
such would be small.
With multiline strings, _any_ change involving quote characters can flip
the string/non-string characterisation from point all the way to the end
of the buffer. In the worst case scenario, this potentially big region
needs to be analysed and have syntax-table text properties throughout
the entire region changed.
The current problem is that c-b-c-check-u-strings is doing this analysis
for every buffer change. This was easier to code, but has led to
performance problems on buffers which aren't small. The solution to
this will have to involve restricting this analysis to when quote marks
or the c-multiline-string-start-char get inserted or removed. That way,
there should only be an occasional and tolerable delay when one of these
characters is inserted/removed.
I'll be looking at this in the coming days.
> Just wanted to let you know.
> Theo
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-28 19:33 ` Alan Mackenzie
@ 2020-09-28 19:41 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 12+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-09-28 19:41 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 43631, Eli Zaretskii
Alan Mackenzie <acm@muc.de> writes:
> Hello, Theo.
>
[...]
>> I see that when I remove 'c-before-change-check-unbalanced-strings from
>> 'c-get-state-before-change-functions' the performance degradation
>> ceases. I'm not sure what else is affected by that change, so not sure
>> if that can be counted as a fix as far as 'csharp-mode' is concerned.
>
> I would strongly recommend you not to make such a change, at least not
> without a good deal of matching changes elsewhere. ;-)
Yeah, I put it back in some time ago ;)
>
> It seems the bit in c-b-c-check-unbalanced-strings dealing with
> multiline strings was written on the assumption that buffers containing
> such would be small.
>
> With multiline strings, _any_ change involving quote characters can flip
> the string/non-string characterisation from point all the way to the end
> of the buffer. In the worst case scenario, this potentially big region
> needs to be analysed and have syntax-table text properties throughout
> the entire region changed.
>
> The current problem is that c-b-c-check-u-strings is doing this analysis
> for every buffer change. This was easier to code, but has led to
> performance problems on buffers which aren't small. The solution to
> this will have to involve restricting this analysis to when quote marks
> or the c-multiline-string-start-char get inserted or removed. That way,
> there should only be an occasional and tolerable delay when one of these
> characters is inserted/removed.
>
> I'll be looking at this in the coming days.
>
Thats very interesting, and thanks!
--
Theo
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
2020-09-26 11:17 bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-26 11:41 ` Eli Zaretskii
@ 2023-10-13 15:26 ` Alan Mackenzie
1 sibling, 0 replies; 12+ messages in thread
From: Alan Mackenzie @ 2023-10-13 15:26 UTC (permalink / raw)
To: 43631-done
Hello, Emacs.
This bug was fixed with my commits between 2021-08-12 and 2021-08-14.
Closing.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-10-13 15:26 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-26 11:17 bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-26 11:41 ` Eli Zaretskii
2020-09-26 12:40 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-26 13:43 ` Eli Zaretskii
2020-09-26 16:03 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-26 16:17 ` Eli Zaretskii
2020-09-26 19:43 ` Dmitry Gutov
2020-09-27 9:54 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-27 11:34 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-28 19:33 ` Alan Mackenzie
2020-09-28 19:41 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-13 15:26 ` Alan Mackenzie
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).