GNU bug report logs -
#48871
27.2; Unusably slow in C# mode
Previous Next
To reply to this bug, email your comments to 48871 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 12:33:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jan <rtm443x <at> googlemail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 06 Jun 2021 12:33:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
I use emacs, I'm not an expert.
C# mode is slow beyond to the point of being completely unusable. This
seems to have started when I upgraded from emacs 26 to emacs 27.2. The
file is ~220K. At the start of the file, typing takes 3 or 4 secs *per
character* to appear (at the end of the file, instantaneous). It's
forcing me to use visual studio to do all simple text editing and I
don't like that.
If I turn off font lock mode it doesn't improve any.
If I switch to fundamental mode it's back to it's snappy self.
Turning off Syntactic Indentation and Electric Mode didn't help.
I tried removing all comments to see what happened but no luck.
I did find this quite recent issue
<https://github.com/emacs-csharp/csharp-mode/issues/200> but their
solution <https://github.com/emacs-csharp/csharp-mode/issues/200#issuecomment-739926801>
didn't help because I couldn't find that text in the specified lisp
file so couldn't comment it out.
I looked on the emacs bug list but found nothing matching (not sure I
was doing the search right though).
I can provide the c# file but I'd prefer it to not be made public if possible.
Turns out emacs has a profiler, thought I'd try it. From
<https://www.gnu.org/software/emacs/manual
/html_node/elisp/Profiling.html> did profiler-start, typed some chars
(probably 20 to 30 secs locked up before it was finished, immediately
did profiler-stop, report is this (heavier parts expanded)
- command-execute 1121 97%
- call-interactively 1121 97%
- funcall-interactively 1114 96%
- self-insert-command 889 77%
- c-before-change 878 76%
- mapc 878 76%
- #<compiled 0x2297aaf> 878 76%
- c-before-change-check-unbalanced-strings 877 76%
c-pps-to-string-delim 865 75%
- c-syntactic-re-search-forward 11 0%
c-beginning-of-macro 4 0%
- c-after-change 11 0%
- mapc 11 0%
- #<compiled 0x2297b19> 11 0%
c-after-change-mark-abnormal-strings 4 0%
- c-restore-<>-properties 4 0%
c-syntactic-re-search-forward 3 0%
- c-forward-<>-arglist 1 0%
- c-forward-<>-arglist-recur 1 0%
c-forward-sws 1 0%
- c-change-expand-fl-region 2 0%
- c-fl-decl-end 2 0%
- c-literal-start 2 0%
- c-semi-pp-to-literal 2 0%
c-parse-ps-state-below 2 0%
c-parse-quotes-after-change 1 0%
- newline 223 19%
- self-insert-command 223 19%
- electric-indent-post-self-insert-function 112 9%
- indent-according-to-mode 112 9%
- c-indent-line 112 9%
- c-shift-line-indentation 112 9%
- c-before-change 110 9%
+ mapc 109 9%
c-restore-string-fences 1 0%
- c-after-change 2 0%
- mapc 2 0%
- #<compiled 0x2297b19> 2 0%
c-after-change-mark-abnormal-strings 1 0%
- c-restore-<>-properties 1 0%
c-syntactic-re-search-forward 1 0%
- c-before-change 110 9%
- mapc 110 9%
- #<compiled 0x2297aaf> 110 9%
- c-before-change-check-unbalanced-strings 110 9%
c-pps-to-string-delim 109 9%
c-syntactic-re-search-forward 1 0%
- c-after-change 1 0%
- mapc 1 0%
- #<compiled 0x2297b19> 1 0%
- c-restore-<>-properties 1 0%
c-syntactic-re-search-forward 1 0%
- execute-extended-command 2 0%
- sit-for 2 0%
redisplay 2 0%
+ byte-code 7 0%
- ... 25 2%
Automatic GC 25 2%
+ redisplay_internal (C function) 5 0%
Not sure what to do.
cheers
jan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 12:50:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 48871 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 6 Jun 2021 13:32:09 +0100
> From: jan via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> C# mode is slow beyond to the point of being completely unusable. This
> seems to have started when I upgraded from emacs 26 to emacs 27.2. The
> file is ~220K. At the start of the file, typing takes 3 or 4 secs *per
> character* to appear (at the end of the file, instantaneous). It's
> forcing me to use visual studio to do all simple text editing and I
> don't like that.
> [...]
> Turns out emacs has a profiler, thought I'd try it.
Good start, thanks.
> Not sure what to do.
Post an example of a file where typing lags by several seconds, and
let's see what people here can tell about that.
But before that, start "emacs -Q", visit the C# file that gave you
such trouble, and try typing there. If the lag disappears, then look
for some of your customizations that could explain the slow responses.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 13:35:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 48871 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
had already tried the -Q option. Emacs started but when I tried "M-x
csharp-mode" it didn't recognise it. I tried exactly the same on the
normally-started emacs to check I was entering it correctly and that
did understand it.
I guess the -Q effectively disables some modes? I was surprised.
Yep, customisation may well be the issue here.
I have a file of equivalent size which should demo the issue but can't
zip it as gmail blocks anything with a zip attached, I can post as
attachment directly but it's 220KBytes, you ok with that on your
mailing list?
cheers
jan
On 06/06/2021, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Sun, 6 Jun 2021 13:32:09 +0100
>> From: jan via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> C# mode is slow beyond to the point of being completely unusable. This
>> seems to have started when I upgraded from emacs 26 to emacs 27.2. The
>> file is ~220K. At the start of the file, typing takes 3 or 4 secs *per
>> character* to appear (at the end of the file, instantaneous). It's
>> forcing me to use visual studio to do all simple text editing and I
>> don't like that.
>> [...]
>> Turns out emacs has a profiler, thought I'd try it.
>
> Good start, thanks.
>
>> Not sure what to do.
>
> Post an example of a file where typing lags by several seconds, and
> let's see what people here can tell about that.
>
> But before that, start "emacs -Q", visit the C# file that gave you
> such trouble, and try typing there. If the lag disappears, then look
> for some of your customizations that could explain the slow responses.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 13:51:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 48871 <at> debbugs.gnu.org (full text, mbox):
> From: jan <rtm443x <at> googlemail.com>
> Date: Sun, 6 Jun 2021 14:34:19 +0100
> Cc: 48871 <at> debbugs.gnu.org
>
> had already tried the -Q option. Emacs started but when I tried "M-x
> csharp-mode" it didn't recognise it. I tried exactly the same on the
> normally-started emacs to check I was entering it correctly and that
> did understand it.
> I guess the -Q effectively disables some modes? I was surprised.
>
> Yep, customisation may well be the issue here.
So let's try to figure out why "emacs -Q" fails to load csharp-mode.
Since there's no such mode bundled with Emacs, I guess you downloaded
it from somewhere? Then try this:
emacs -Q
M-x load-file RET /path/to/csharp-mode.el RE
The last line assumes that the Lisp file which defines the function
csharp-mode is called csharp-mode.el; if not, change the file name to
fit the reality. Also, "/path/to/" should be replaced with the actual
absolute file name of the file on your system.
Then say what you tried:
M-x csharp-mode RET
If that still doesn't work, please show the error messages. Likely
they will identify packages csharp-mode depends on that you also need
to load with "M-x load-file".
> I have a file of equivalent size which should demo the issue but can't
> zip it as gmail blocks anything with a zip attached, I can post as
> attachment directly but it's 220KBytes, you ok with that on your
> mailing list?
Yes, it's okay. But let's first try and see whether "emacs -Q"
exhibits the same problem, okay?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 14:54:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 48871 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I don't recall installing c# but may well have happened.
From package-list-packages:
csharp-mode 20210328.2004 installed C# mode derived mode
Which does not say built-in so likely I did. Looking in the unzipped
emacs 27.2 , no relevant *sharp* file in it, and did find it in the
elpa directory, so I guess must have.
Started with -Q. Did the M-x load-file for csharp-mode.el (FYI also
had to do load-file for csharp-compilation.el before that to make it
happy).
Finally got to load the C# file itself, exactly the same. No faster.
Troublesome C# file attached.
cheers
jan
On 06/06/2021, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: jan <rtm443x <at> googlemail.com>
>> Date: Sun, 6 Jun 2021 14:34:19 +0100
>> Cc: 48871 <at> debbugs.gnu.org
>>
>> had already tried the -Q option. Emacs started but when I tried "M-x
>> csharp-mode" it didn't recognise it. I tried exactly the same on the
>> normally-started emacs to check I was entering it correctly and that
>> did understand it.
>> I guess the -Q effectively disables some modes? I was surprised.
>>
>> Yep, customisation may well be the issue here.
>
> So let's try to figure out why "emacs -Q" fails to load csharp-mode.
> Since there's no such mode bundled with Emacs, I guess you downloaded
> it from somewhere? Then try this:
>
> emacs -Q
> M-x load-file RET /path/to/csharp-mode.el RE
>
> The last line assumes that the Lisp file which defines the function
> csharp-mode is called csharp-mode.el; if not, change the file name to
> fit the reality. Also, "/path/to/" should be replaced with the actual
> absolute file name of the file on your system.
>
> Then say what you tried:
>
> M-x csharp-mode RET
>
> If that still doesn't work, please show the error messages. Likely
> they will identify packages csharp-mode depends on that you also need
> to load with "M-x load-file".
>
>> I have a file of equivalent size which should demo the issue but can't
>> zip it as gmail blocks anything with a zip attached, I can post as
>> attachment directly but it's 220KBytes, you ok with that on your
>> mailing list?
>
> Yes, it's okay. But let's first try and see whether "emacs -Q"
> exhibits the same problem, okay?
>
[expression.cs (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 17:02:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 48871 <at> debbugs.gnu.org (full text, mbox):
> From: jan <rtm443x <at> googlemail.com>
> Date: Sun, 6 Jun 2021 15:53:11 +0100
> Cc: 48871 <at> debbugs.gnu.org
>
> I don't recall installing c# but may well have happened.
> >From package-list-packages:
>
> csharp-mode 20210328.2004 installed C# mode derived mode
>
> Which does not say built-in so likely I did. Looking in the unzipped
> emacs 27.2 , no relevant *sharp* file in it, and did find it in the
> elpa directory, so I guess must have.
>
> Started with -Q. Did the M-x load-file for csharp-mode.el (FYI also
> had to do load-file for csharp-compilation.el before that to make it
> happy).
>
> Finally got to load the C# file itself, exactly the same. No faster.
>
> Troublesome C# file attached.
Thanks.
Alan, can you look into this? It could be some problem in
csharp-mode, but the profiler says 97% of the time is spent in a CC
mode code, so maybe you can shed some light on this?
I see that almost the entire 6896-line file is enclosed in a single
"namespace LDB { ... }" block, maybe this is the reason?
Here's the main portion of a profile measured on my system from just
inserting 3 characters at BOB of the file attached by the OP. An
unoptimized build of Emacs 28 took about 2 min(!) to process those 3
self-inserting characters.
8693 98% - command-execute
8693 98% - call-interactively
8693 98% - funcall-interactively
8690 98% - self-insert-command
8627 98% - c-before-change
8627 98% - mapc
8627 98% - #<compiled 0x1aaa1ff2c62de223>
8627 98% - c-before-change-check-unbalanced-strings
8611 97% c-pps-to-string-delim
10 0% - c-syntactic-re-search-forward
2 0% - c-beginning-of-macro
2 0% back-to-indentation
1 0% #<compiled 0x4f47ef635173>
1 0% c-clear-syn-tab
63 0% - c-after-change
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 18:02:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 48871 <at> debbugs.gnu.org (full text, mbox):
Looks like strings doing it.
Go to fundamental mode (or search&replace will take forever),
completely remove all strings with regex replace:
".*?" ->
Save file then close and reopen emacs, reopen file, ensure it's in
csharp mode, char insertion is almost back to normal.
That is, remove strings entirely. Just replacing them with empty
strings "" didn't help.
cheers
jan
On 06/06/2021, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: jan <rtm443x <at> googlemail.com>
>> Date: Sun, 6 Jun 2021 15:53:11 +0100
>> Cc: 48871 <at> debbugs.gnu.org
>>
>> I don't recall installing c# but may well have happened.
>> >From package-list-packages:
>>
>> csharp-mode 20210328.2004 installed C# mode derived
>> mode
>>
>> Which does not say built-in so likely I did. Looking in the unzipped
>> emacs 27.2 , no relevant *sharp* file in it, and did find it in the
>> elpa directory, so I guess must have.
>>
>> Started with -Q. Did the M-x load-file for csharp-mode.el (FYI also
>> had to do load-file for csharp-compilation.el before that to make it
>> happy).
>>
>> Finally got to load the C# file itself, exactly the same. No faster.
>>
>> Troublesome C# file attached.
>
> Thanks.
>
> Alan, can you look into this? It could be some problem in
> csharp-mode, but the profiler says 97% of the time is spent in a CC
> mode code, so maybe you can shed some light on this?
>
> I see that almost the entire 6896-line file is enclosed in a single
> "namespace LDB { ... }" block, maybe this is the reason?
>
> Here's the main portion of a profile measured on my system from just
> inserting 3 characters at BOB of the file attached by the OP. An
> unoptimized build of Emacs 28 took about 2 min(!) to process those 3
> self-inserting characters.
>
> 8693 98% - command-execute
> 8693 98% - call-interactively
> 8693 98% - funcall-interactively
> 8690 98% - self-insert-command
> 8627 98% - c-before-change
> 8627 98% - mapc
> 8627 98% - #<compiled 0x1aaa1ff2c62de223>
> 8627 98% - c-before-change-check-unbalanced-strings
> 8611 97% c-pps-to-string-delim
> 10 0% - c-syntactic-re-search-forward
> 2 0% - c-beginning-of-macro
> 2 0% back-to-indentation
> 1 0% #<compiled 0x4f47ef635173>
> 1 0% c-clear-syn-tab
> 63 0% - c-after-change
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 18:10:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 48871 <at> debbugs.gnu.org (full text, mbox):
> From: jan <rtm443x <at> googlemail.com>
> Date: Sun, 6 Jun 2021 19:00:57 +0100
> Cc: Alan Mackenzie <acm <at> muc.de>, 48871 <at> debbugs.gnu.org
>
> Looks like strings doing it.
Well, the fact that c-pps-to-string-delim is the hot spot kinda says
that...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 18:23:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 48871 <at> debbugs.gnu.org (full text, mbox):
Ah... well... yeah...
searching for "c-pps-to-string-delim" finds this
<https://github.com/emacs-csharp/csharp-mode/issues/207>, similar to
what I referenced in my initial post.
Neither are very optimistic. If this is a wontfix I'll understand.
cheers
jan
On 06/06/2021, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: jan <rtm443x <at> googlemail.com>
>> Date: Sun, 6 Jun 2021 19:00:57 +0100
>> Cc: Alan Mackenzie <acm <at> muc.de>, 48871 <at> debbugs.gnu.org
>>
>> Looks like strings doing it.
>
> Well, the fact that c-pps-to-string-delim is the hot spot kinda says
> that...
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Sun, 06 Jun 2021 19:28:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 48871 <at> debbugs.gnu.org (full text, mbox):
Hello, Jan and Eli.
On Sun, Jun 06, 2021 at 19:22:17 +0100, jan wrote:
> Ah... well... yeah...
> searching for "c-pps-to-string-delim" finds this
> <https://github.com/emacs-csharp/csharp-mode/issues/207>, similar to
> what I referenced in my initial post.
> Neither are very optimistic. If this is a wontfix I'll understand.
This is indeed a string problem in CC Mode. More precisely, it's a
multi-line string problem, such being started in C# mode by @". For
some very bad reason (which I've got written down somewhere) CC Mode is
scanning to the end of the buffer for each character inserted. Sorry.
As a workaround, if you don't have any multi-line strings in your
source, put the following in your csharp-mode-hook:
(setq c-multiline-string-start-char nil)
.. That should get rid of the excessive scanning for the time being.
I've spent much of the last few weeks adapting the C++ raw string
mechanism also to handle multi-line strings in other languages such as
C#. I'm hoping to have it up and running soon. Then, perhaps, the C#
Mode maintainer will incorporate it into C# Mode, which should be a
straightforward task.
> cheers
> jan
> On 06/06/2021, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> From: jan <rtm443x <at> googlemail.com>
> >> Date: Sun, 6 Jun 2021 19:00:57 +0100
> >> Cc: Alan Mackenzie <acm <at> muc.de>, 48871 <at> debbugs.gnu.org
> >> Looks like strings doing it.
> > Well, the fact that c-pps-to-string-delim is the hot spot kinda says
> > that...
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48871; Package
emacs.
(Wed, 09 Jun 2021 11:07:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 48871 <at> debbugs.gnu.org (full text, mbox):
I forgot to provide feedback to this list, this workaround restored performance.
jan
(Thanks to Alan Mackenzie for this, and his continuing work to fix the
underlying problem)
On 06/06/2021, Alan Mackenzie <acm <at> muc.de> wrote:
> Hello, Jan and Eli.
>
> On Sun, Jun 06, 2021 at 19:22:17 +0100, jan wrote:
>> Ah... well... yeah...
>
>> searching for "c-pps-to-string-delim" finds this
>> <https://github.com/emacs-csharp/csharp-mode/issues/207>, similar to
>> what I referenced in my initial post.
>> Neither are very optimistic. If this is a wontfix I'll understand.
>
> This is indeed a string problem in CC Mode. More precisely, it's a
> multi-line string problem, such being started in C# mode by @". For
> some very bad reason (which I've got written down somewhere) CC Mode is
> scanning to the end of the buffer for each character inserted. Sorry.
>
> As a workaround, if you don't have any multi-line strings in your
> source, put the following in your csharp-mode-hook:
>
> (setq c-multiline-string-start-char nil)
>
> .. That should get rid of the excessive scanning for the time being.
>
> I've spent much of the last few weeks adapting the C++ raw string
> mechanism also to handle multi-line strings in other languages such as
> C#. I'm hoping to have it up and running soon. Then, perhaps, the C#
> Mode maintainer will incorporate it into C# Mode, which should be a
> straightforward task.
>
>> cheers
>
>> jan
>
>
>> On 06/06/2021, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> >> From: jan <rtm443x <at> googlemail.com>
>> >> Date: Sun, 6 Jun 2021 19:00:57 +0100
>> >> Cc: Alan Mackenzie <acm <at> muc.de>, 48871 <at> debbugs.gnu.org
>
>> >> Looks like strings doing it.
>
>> > Well, the fact that c-pps-to-string-delim is the hot spot kinda says
>> > that...
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
This bug report was last modified 3 years and 167 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.