Package: emacs;
Reported by: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Date: Mon, 16 Jul 2018 13:38:02 UTC
Severity: normal
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32175 in the body.
You can then email your comments to 32175 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#32175; Package emacs.
(Mon, 16 Jul 2018 13:38:03 GMT) Full text and rfc822 format available.Konstantin Kharlamov <hi-angel <at> yandex.ru>:bug-gnu-emacs <at> gnu.org.
(Mon, 16 Jul 2018 13:38:03 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Konstantin Kharlamov <hi-angel <at> yandex.ru> To: bug-gnu-emacs <at> gnu.org Subject: Terrible performance of c++-mode refontifying Date: Mon, 16 Jul 2018 16:36:29 +0300
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%
bug-gnu-emacs <at> gnu.org:bug#32175; Package emacs.
(Sun, 17 May 2020 03:51:01 GMT) Full text and rfc822 format available.Message #8 received at 32175 <at> debbugs.gnu.org (full text, mbox):
From: Stefan Kangas <stefan <at> marxist.se> To: Alan Mackenzie <acm <at> muc.de> Cc: Konstantin Kharlamov <hi-angel <at> yandex.ru>, 32175 <at> debbugs.gnu.org Subject: Re: bug#32175: Terrible performance of c++-mode refontifying Date: Sat, 16 May 2020 20:49:58 -0700
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 <at> 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%
bug-gnu-emacs <at> gnu.org:bug#32175; Package emacs.
(Sun, 17 May 2020 09:57:02 GMT) Full text and rfc822 format available.Message #11 received at 32175 <at> debbugs.gnu.org (full text, mbox):
From: Konstantin Kharlamov <hi-angel <at> yandex.ru> To: Stefan Kangas <stefan <at> marxist.se>, Alan Mackenzie <acm <at> muc.de> Cc: 32175 <at> debbugs.gnu.org Subject: Re: bug#32175: Terrible performance of c++-mode refontifying Date: Sun, 17 May 2020 12:56:27 +0300
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 <at> 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%
bug-gnu-emacs <at> gnu.org:bug#32175; Package emacs.
(Sun, 17 May 2020 14:02:02 GMT) Full text and rfc822 format available.Message #14 received at 32175 <at> debbugs.gnu.org (full text, mbox):
From: Stefan Kangas <stefan <at> marxist.se> To: Konstantin Kharlamov <hi-angel <at> yandex.ru>, Alan Mackenzie <acm <at> muc.de> Cc: 32175 <at> debbugs.gnu.org Subject: Re: bug#32175: Terrible performance of c++-mode refontifying Date: Sun, 17 May 2020 07:01:00 -0700
Konstantin Kharlamov <hi-angel <at> 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
bug-gnu-emacs <at> gnu.org:bug#32175; Package emacs.
(Sun, 17 May 2020 14:07:01 GMT) Full text and rfc822 format available.Message #17 received at 32175 <at> debbugs.gnu.org (full text, mbox):
From: Konstantin Kharlamov <hi-angel <at> yandex.ru> To: Stefan Kangas <stefan <at> marxist.se>, Alan Mackenzie <acm <at> muc.de> Cc: 32175 <at> debbugs.gnu.org Subject: Re: bug#32175: Terrible performance of c++-mode refontifying Date: Sun, 17 May 2020 17:06:45 +0300
On 5/17/20 5:01 PM, Stefan Kangas wrote: > Konstantin Kharlamov <hi-angel <at> 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
bug-gnu-emacs <at> gnu.org:bug#32175; Package emacs.
(Sun, 17 May 2020 14:10:01 GMT) Full text and rfc822 format available.Message #20 received at 32175 <at> debbugs.gnu.org (full text, mbox):
From: Konstantin Kharlamov <hi-angel <at> yandex.ru> To: Stefan Kangas <stefan <at> marxist.se>, Alan Mackenzie <acm <at> muc.de> Cc: 32175 <at> debbugs.gnu.org Subject: Re: bug#32175: Terrible performance of c++-mode refontifying Date: Sun, 17 May 2020 17:09:43 +0300
On 5/17/20 5:06 PM, Konstantin Kharlamov wrote:
> On 5/17/20 5:01 PM, Stefan Kangas wrote:
>> Konstantin Kharlamov <hi-angel <at> 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.
Stefan Kangas <stefan <at> marxist.se>:Konstantin Kharlamov <hi-angel <at> yandex.ru>:Message #25 received at 32175-done <at> debbugs.gnu.org (full text, mbox):
From: Stefan Kangas <stefan <at> marxist.se> To: Konstantin Kharlamov <hi-angel <at> yandex.ru>, Alan Mackenzie <acm <at> muc.de> Cc: 32175-done <at> debbugs.gnu.org Subject: Re: bug#32175: Terrible performance of c++-mode refontifying Date: Sun, 17 May 2020 07:27:09 -0700
Konstantin Kharlamov <hi-angel <at> 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
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Mon, 15 Jun 2020 11:24:07 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.