bug#10149: Emacs 24 hangs for several minutes with very large c++ files

[Alan Mackenzie]

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).