* bug#32175: Terrible performance of c++-mode refontifying
@ 2018-07-16 13:36 Konstantin Kharlamov
2020-05-17 3:49 ` Stefan Kangas
0 siblings, 1 reply; 7+ messages in thread
From: Konstantin Kharlamov @ 2018-07-16 13:36 UTC (permalink / raw)
To: 32175
Sometimes for working with C++ code I start experiencing lags for typing
the text, like, 1-second delay between pressing the key and the actual
text appearing. This does not happen at the beginning of the work, but
rather after Emacs have been running for a while.
It seems to be a per-buffer issue. E.g. right now I
have the problem in one c++mode buffer, but not in another.
This problem have definitely existed for 2 years (maybe more). I
didn't report it because I thought it's my computer slow. I attached
profiling result at the end, and I remember that some years ago traces
of low performance have also been leading to functions about
refontifying.
Emacs version: GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+
Version 3.22.30) of 2018-07-06
(It's 12 days old build from git, commit 3bbd4ffc68b)
FWIW it's built with -flto -march=native options, i.e. I have as much
optimization as possible.
Profiling below is done by pressing <SPACE> key, then waiting for
symbol to appear; and repeating this for ≈10 times.
- redisplay_internal (C function) 6900 69%
- jit-lock-function 6887 69%
- jit-lock-fontify-now 6887 69%
- jit-lock--run-functions 6873 69%
- run-hook-wrapped 6873 69%
- #<compiled 0x289f6f5> 6873 69%
- font-lock-fontify-region 6873 69%
- c-font-lock-fontify-region 6866 69%
- font-lock-default-fontify-region 6514 65%
- font-lock-fontify-keywords-region 6447 65%
- c-font-lock-declarations 5059 51%
- c-find-decl-spots 5012 50%
- c-bs-at-toplevel-p 2972 29%
- c-brace-stack-at 2937 29%
- c-update-brace-stack 2831 28%
- c-syntactic-re-search-forward 1263 12%
+ c-beginning-of-macro 548 5%
#<compiled 0x14ed36d> 6 0%
- c-forward-<>-arglist 1220 12%
- c-forward-<>-arglist-recur 1041 10%
+ c-syntactic-re-search-forward 285 2%
+ c-forward-<>-arglist-recur 245 2%
+ c-backward-token-2 125 1%
c-forward-sws 52 0%
+ c-backward-sws 12 0%
c-beginning-of-current-token 48 0%
match-string-no-properties 6 0%
+ #<compiled 0x1503add> 1823 18%
+ c-beginning-of-macro 40 0%
c-backward-sws 8 0%
c-forward-sws 6 0%
#<compiled 0x14ed6cd> 4 0%
+ c-backward-token-2 3 0%
+ c-font-lock-enclosing-decls 240 2%
+ #<compiled 0x150a5d1> 203 2%
+ c-font-lock-<>-arglists 183 1%
+ c-font-lock-cut-off-declarators 176 1%
+ color-identifiers:colorize 140 1%
+ c-font-lock-raw-strings 45 0%
+ c-font-lock-invalid-single-quotes 37 0%
+ c-font-lock-enum-tail 34 0%
#<compiled 0x150a4f1> 31 0%
#<compiled 0x150a1cd> 29 0%
+ c-font-lock-complex-decl-prepare 25 0%
#<compiled 0x150a495> 24 0%
#<compiled 0x150a57d> 22 0%
+ c-font-lock-c++-lambda-captures 18 0%
#<compiled 0x150a555> 9 0%
#<compiled 0x150a535> 3 0%
eval 3 0%
c-font-lock-enum-body 3 0%
+ font-lock-fontify-syntactically-region 40 0%
+ c-before-context-fl-expand-region 348 3%
+ eval 9 0%
+ mode-line-default-help-echo 4 0%
- ... 1411 14%
Automatic GC 1411 14%
+ command-execute 1252 12%
+ flycheck-handle-signal 301 3%
+ timer-event-handler 32 0%
+ evil-repeat-post-hook 5 0%
global-highlight-symbol-mode-check-buffers 5 0%
evil--jump-hook 1 0%
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#32175: Terrible performance of c++-mode refontifying
2018-07-16 13:36 bug#32175: Terrible performance of c++-mode refontifying Konstantin Kharlamov
@ 2020-05-17 3:49 ` Stefan Kangas
2020-05-17 9:56 ` Konstantin Kharlamov
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Kangas @ 2020-05-17 3:49 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 32175, Konstantin Kharlamov
Hi Alan,
This bug was reported in July 2018 but got no followup.
Perhaps you could take a look?
Best regards,
Stefan Kangas
Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> Sometimes for working with C++ code I start experiencing lags for typing
> the text, like, 1-second delay between pressing the key and the actual
> text appearing. This does not happen at the beginning of the work, but
> rather after Emacs have been running for a while.
>
> It seems to be a per-buffer issue. E.g. right now I
> have the problem in one c++mode buffer, but not in another.
>
> This problem have definitely existed for 2 years (maybe more). I
> didn't report it because I thought it's my computer slow. I attached
> profiling result at the end, and I remember that some years ago traces
> of low performance have also been leading to functions about
> refontifying.
>
> Emacs version: GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
> 3.22.30) of 2018-07-06
> (It's 12 days old build from git, commit 3bbd4ffc68b)
>
> FWIW it's built with -flto -march=native options, i.e. I have as much
> optimization as possible.
>
> Profiling below is done by pressing <SPACE> key, then waiting for
> symbol to appear; and repeating this for ≈10 times.
>
> - redisplay_internal (C function) 6900 69%
> - jit-lock-function 6887 69%
> - jit-lock-fontify-now 6887 69%
> - jit-lock--run-functions 6873 69%
> - run-hook-wrapped 6873 69%
> - #<compiled 0x289f6f5> 6873 69%
> - font-lock-fontify-region 6873 69%
> - c-font-lock-fontify-region 6866 69%
> - font-lock-default-fontify-region 6514 65%
> - font-lock-fontify-keywords-region 6447 65%
> - c-font-lock-declarations 5059 51%
> - c-find-decl-spots 5012 50%
> - c-bs-at-toplevel-p 2972 29%
> - c-brace-stack-at 2937 29%
> - c-update-brace-stack 2831 28%
> - c-syntactic-re-search-forward 1263 12%
> + c-beginning-of-macro 548 5%
> #<compiled 0x14ed36d> 6 0%
> - c-forward-<>-arglist 1220 12%
> - c-forward-<>-arglist-recur 1041 10%
> + c-syntactic-re-search-forward 285 2%
> + c-forward-<>-arglist-recur 245 2%
> + c-backward-token-2 125 1%
> c-forward-sws 52 0%
> + c-backward-sws 12 0%
> c-beginning-of-current-token 48 0%
> match-string-no-properties 6 0%
> + #<compiled 0x1503add> 1823 18%
> + c-beginning-of-macro 40 0%
> c-backward-sws 8 0%
> c-forward-sws 6 0%
> #<compiled 0x14ed6cd> 4 0%
> + c-backward-token-2 3 0%
> + c-font-lock-enclosing-decls 240 2%
> + #<compiled 0x150a5d1> 203 2%
> + c-font-lock-<>-arglists 183 1%
> + c-font-lock-cut-off-declarators 176 1%
> + color-identifiers:colorize 140 1%
> + c-font-lock-raw-strings 45 0%
> + c-font-lock-invalid-single-quotes 37 0%
> + c-font-lock-enum-tail 34 0%
> #<compiled 0x150a4f1> 31 0%
> #<compiled 0x150a1cd> 29 0%
> + c-font-lock-complex-decl-prepare 25 0%
> #<compiled 0x150a495> 24 0%
> #<compiled 0x150a57d> 22 0%
> + c-font-lock-c++-lambda-captures 18 0%
> #<compiled 0x150a555> 9 0%
> #<compiled 0x150a535> 3 0%
> eval 3 0%
> c-font-lock-enum-body 3 0%
> + font-lock-fontify-syntactically-region 40 0%
> + c-before-context-fl-expand-region 348 3%
> + eval 9 0%
> + mode-line-default-help-echo 4 0%
> - ... 1411 14%
> Automatic GC 1411 14%
> + command-execute 1252 12%
> + flycheck-handle-signal 301 3%
> + timer-event-handler 32 0%
> + evil-repeat-post-hook 5 0%
> global-highlight-symbol-mode-check-buffers 5 0%
> evil--jump-hook 1 0%
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#32175: Terrible performance of c++-mode refontifying
2020-05-17 3:49 ` Stefan Kangas
@ 2020-05-17 9:56 ` Konstantin Kharlamov
2020-05-17 14:01 ` Stefan Kangas
0 siblings, 1 reply; 7+ messages in thread
From: Konstantin Kharlamov @ 2020-05-17 9:56 UTC (permalink / raw)
To: Stefan Kangas, Alan Mackenzie; +Cc: 32175
Thanks! I should note, I haven't seen this problem for a while. But I struggle to say if it's been fixed or is it because hw I work on got more powerful.
On 5/17/20 6:49 AM, Stefan Kangas wrote:
> Hi Alan,
>
> This bug was reported in July 2018 but got no followup.
>
> Perhaps you could take a look?
>
> Best regards,
> Stefan Kangas
>
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>
>> Sometimes for working with C++ code I start experiencing lags for typing
>> the text, like, 1-second delay between pressing the key and the actual
>> text appearing. This does not happen at the beginning of the work, but
>> rather after Emacs have been running for a while.
>>
>> It seems to be a per-buffer issue. E.g. right now I
>> have the problem in one c++mode buffer, but not in another.
>>
>> This problem have definitely existed for 2 years (maybe more). I
>> didn't report it because I thought it's my computer slow. I attached
>> profiling result at the end, and I remember that some years ago traces
>> of low performance have also been leading to functions about
>> refontifying.
>>
>> Emacs version: GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
>> 3.22.30) of 2018-07-06
>> (It's 12 days old build from git, commit 3bbd4ffc68b)
>>
>> FWIW it's built with -flto -march=native options, i.e. I have as much
>> optimization as possible.
>>
>> Profiling below is done by pressing <SPACE> key, then waiting for
>> symbol to appear; and repeating this for ≈10 times.
>>
>> - redisplay_internal (C function) 6900 69%
>> - jit-lock-function 6887 69%
>> - jit-lock-fontify-now 6887 69%
>> - jit-lock--run-functions 6873 69%
>> - run-hook-wrapped 6873 69%
>> - #<compiled 0x289f6f5> 6873 69%
>> - font-lock-fontify-region 6873 69%
>> - c-font-lock-fontify-region 6866 69%
>> - font-lock-default-fontify-region 6514 65%
>> - font-lock-fontify-keywords-region 6447 65%
>> - c-font-lock-declarations 5059 51%
>> - c-find-decl-spots 5012 50%
>> - c-bs-at-toplevel-p 2972 29%
>> - c-brace-stack-at 2937 29%
>> - c-update-brace-stack 2831 28%
>> - c-syntactic-re-search-forward 1263 12%
>> + c-beginning-of-macro 548 5%
>> #<compiled 0x14ed36d> 6 0%
>> - c-forward-<>-arglist 1220 12%
>> - c-forward-<>-arglist-recur 1041 10%
>> + c-syntactic-re-search-forward 285 2%
>> + c-forward-<>-arglist-recur 245 2%
>> + c-backward-token-2 125 1%
>> c-forward-sws 52 0%
>> + c-backward-sws 12 0%
>> c-beginning-of-current-token 48 0%
>> match-string-no-properties 6 0%
>> + #<compiled 0x1503add> 1823 18%
>> + c-beginning-of-macro 40 0%
>> c-backward-sws 8 0%
>> c-forward-sws 6 0%
>> #<compiled 0x14ed6cd> 4 0%
>> + c-backward-token-2 3 0%
>> + c-font-lock-enclosing-decls 240 2%
>> + #<compiled 0x150a5d1> 203 2%
>> + c-font-lock-<>-arglists 183 1%
>> + c-font-lock-cut-off-declarators 176 1%
>> + color-identifiers:colorize 140 1%
>> + c-font-lock-raw-strings 45 0%
>> + c-font-lock-invalid-single-quotes 37 0%
>> + c-font-lock-enum-tail 34 0%
>> #<compiled 0x150a4f1> 31 0%
>> #<compiled 0x150a1cd> 29 0%
>> + c-font-lock-complex-decl-prepare 25 0%
>> #<compiled 0x150a495> 24 0%
>> #<compiled 0x150a57d> 22 0%
>> + c-font-lock-c++-lambda-captures 18 0%
>> #<compiled 0x150a555> 9 0%
>> #<compiled 0x150a535> 3 0%
>> eval 3 0%
>> c-font-lock-enum-body 3 0%
>> + font-lock-fontify-syntactically-region 40 0%
>> + c-before-context-fl-expand-region 348 3%
>> + eval 9 0%
>> + mode-line-default-help-echo 4 0%
>> - ... 1411 14%
>> Automatic GC 1411 14%
>> + command-execute 1252 12%
>> + flycheck-handle-signal 301 3%
>> + timer-event-handler 32 0%
>> + evil-repeat-post-hook 5 0%
>> global-highlight-symbol-mode-check-buffers 5 0%
>> evil--jump-hook 1 0%
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#32175: Terrible performance of c++-mode refontifying
2020-05-17 9:56 ` Konstantin Kharlamov
@ 2020-05-17 14:01 ` Stefan Kangas
2020-05-17 14:06 ` Konstantin Kharlamov
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Kangas @ 2020-05-17 14:01 UTC (permalink / raw)
To: Konstantin Kharlamov, Alan Mackenzie; +Cc: 32175
Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> Thanks! I should note, I haven't seen this problem for a while. But I
> struggle to say if it's been fixed or is it because hw I work on got
> more powerful.
Maybe we should just assume it has been fixed then? It seems to me that
it's hard to debug without an example file which exhibits this
behaviour.
I also know that Alan Mackenzie has been fixing a number of performance
issues lately.
Alan, what do you think?
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#32175: Terrible performance of c++-mode refontifying
2020-05-17 14:01 ` Stefan Kangas
@ 2020-05-17 14:06 ` Konstantin Kharlamov
2020-05-17 14:09 ` Konstantin Kharlamov
2020-05-17 14:27 ` Stefan Kangas
0 siblings, 2 replies; 7+ messages in thread
From: Konstantin Kharlamov @ 2020-05-17 14:06 UTC (permalink / raw)
To: Stefan Kangas, Alan Mackenzie; +Cc: 32175
On 5/17/20 5:01 PM, Stefan Kangas wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>
>> Thanks! I should note, I haven't seen this problem for a while. But I
>> struggle to say if it's been fixed or is it because hw I work on got
>> more powerful.
>
> Maybe we should just assume it has been fixed then? It seems to me that
> it's hard to debug without an example file which exhibits this
> behaviour.
As a reporter, I agree. Should anyone stumble upon this again, I think they should create a new report.
FTR: the Emacs version I'm currently using is a build from git dated by 13.09.2019
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#32175: Terrible performance of c++-mode refontifying
2020-05-17 14:06 ` Konstantin Kharlamov
@ 2020-05-17 14:09 ` Konstantin Kharlamov
2020-05-17 14:27 ` Stefan Kangas
1 sibling, 0 replies; 7+ messages in thread
From: Konstantin Kharlamov @ 2020-05-17 14:09 UTC (permalink / raw)
To: Stefan Kangas, Alan Mackenzie; +Cc: 32175
On 5/17/20 5:06 PM, Konstantin Kharlamov wrote:
> On 5/17/20 5:01 PM, Stefan Kangas wrote:
>> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>>
>>> Thanks! I should note, I haven't seen this problem for a while. But I
>>> struggle to say if it's been fixed or is it because hw I work on got
>>> more powerful.
>>
>> Maybe we should just assume it has been fixed then? It seems to me that
>> it's hard to debug without an example file which exhibits this
>> behaviour.
>
> As a reporter, I agree. Should anyone stumble upon this again, I think they should create a new report.
>
> FTR: the Emacs version I'm currently using is a build from git dated by 13.09.2019
Oh, I figured there's one thing in my current setup I should explicitly mention! It is this:
;; run garbage collection only when idle
(setq gc-cons-threshold most-positive-fixnum)
(run-with-idle-timer 2 t (lambda () (garbage-collect)))
Looking at the original stack, I see GC was taking 14%, so it may or may not be relevant.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#32175: Terrible performance of c++-mode refontifying
2020-05-17 14:06 ` Konstantin Kharlamov
2020-05-17 14:09 ` Konstantin Kharlamov
@ 2020-05-17 14:27 ` Stefan Kangas
1 sibling, 0 replies; 7+ messages in thread
From: Stefan Kangas @ 2020-05-17 14:27 UTC (permalink / raw)
To: Konstantin Kharlamov, Alan Mackenzie; +Cc: 32175-done
Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> As a reporter, I agree. Should anyone stumble upon this again, I think
> they should create a new report.
Thanks, so I'm closing this bug now.
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-05-17 14:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-16 13:36 bug#32175: Terrible performance of c++-mode refontifying Konstantin Kharlamov
2020-05-17 3:49 ` Stefan Kangas
2020-05-17 9:56 ` Konstantin Kharlamov
2020-05-17 14:01 ` Stefan Kangas
2020-05-17 14:06 ` Konstantin Kharlamov
2020-05-17 14:09 ` Konstantin Kharlamov
2020-05-17 14:27 ` Stefan Kangas
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).