[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10149: Emacs 24 hangs for several minutes with very large c++ files
From: |
Alan Mackenzie |
Subject: |
bug#10149: Emacs 24 hangs for several minutes with very large c++ files |
Date: |
Sat, 2 Nov 2019 10:09:31 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, Stefan and Eli.
On Sat, Nov 02, 2019 at 00:14:44 +0100, Stefan Kangas wrote:
> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
> > Hi Emacs devs,
> > I am seeing a weird problem. I have an automatically generated C++ class
> > for some ntupled data for quick (but dirty) analysis. It has lots of
> > (~1k) data members. Every time I try to navigate in that file and I
> > reach the large block of text where the data members are declared[1],
> > Emacs takes a long time to move the cursor (e.g. with commands like
> > forward-paragraph or backward-paragraph) and the CPU usage on my
> > Thinkpad X201 maxes out on one of the 4 logical cores. If I wait long
> > enough (several minutes), Emacs 24 does manage to move the cursor to the
> > end of the paragraph. However I don't see this problem with Emacs 23.3.1
> > (or vim).
> > I can replicate this behaviour with `emacs -Q'. The file that causes the
> > issue is attached with this email. I am using Emacs from the repo.or.cz
> > git mirror.
> > commit aecaa1ffa122258c0fbc580ccbfad268ea46b89d
> > Author: Andreas Schwab <schwab@linux-m68k.org>
> > Date: Sat Nov 26 10:10:36 2011 +0100
> > * grammars/bovine-grammar.el (bovine--grammar-newstyle-unquote):
> > Avoid warning about old-style backquote.
> > This is how I compile emacs:
> > In GNU Emacs 24.0.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.7)
> > of 2011-11-27 on mylaptop.example.com
> > configured using `configure '--prefix=/opt/emacs-lisp'
> > '--with-selinux' '--with-imagemagick''
> > Important settings:
> > value of $LC_ALL: nil
> > value of $LC_COLLATE: nil
> > value of $LC_CTYPE: nil
> > value of $LC_MESSAGES: nil
> > value of $LC_MONETARY: nil
> > value of $LC_NUMERIC: nil
> > value of $LC_TIME: nil
> > value of $LANG: en_IN.UTF-8
> > value of $XMODIFIERS: @im=ibus
> > locale-coding-system: utf-8-unix
> > default enable-multibyte-characters: t
> > Since I don't actually get a backtrace, I am not sure what else I can
> > provide. Please feel free to ask me if you need more information.
> > Hope this helps.
> > Footnotes:
> > [1] The large chunk of commented text in the attached file
> I do see a significant slowdown in navigating the file once I comment
> out the block of code. It doesn't hang for several minutes for me,
> but it takes 5-10 seconds for C-v, M-v depending on where point is.
Yes. Scrolling speed has been a constant theme over the last few years,
and several improvements have been made. However ....
> Alan, any comments on this?
Thanks for the profiler output, Eli.
The problem is indeed in c-font-lock-single-decl, where the code is
searching backwards for a possible opening paren of a `for' statement.
It was using (in effect) backward-up-list without a limit for this. This
steadily got slower as one moved further down the class, away from the
class's opening {.
The solution is to supply a limit to that search. I think the following
patch should do the job. For me it speeds up a complete scroll from
beginning to end of buffer by a factor of ~4:
diff -r 2783baa48d44 cc-fonts.el
--- a/cc-fonts.el Fri Oct 25 20:00:14 2019 +0000
+++ b/cc-fonts.el Sat Nov 02 10:01:47 2019 +0000
@@ -1245,7 +1245,7 @@
(if (save-excursion
(and
(car (cddr decl-or-cast)) ; maybe-expression flag.
- (c-go-up-list-backward)
+ (c-go-up-list-backward nil (c-determine-limit 500))
(eq (char-after) ?\()
(progn (c-backward-syntactic-ws)
(c-simple-skip-symbol-backward))
I will commit this properly probably later today, assuming nothing
further untoward is found.
> Best regards,
> Stefan Kangas
--
Alan Mackenzie (Nuremberg, Germany).