unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Kangas <stefan@marxist.se>, Eli Zaretskii <eliz@gnu.org>
Cc: 10149@debbugs.gnu.org, suvayu ali <fatkasuvayu+linux@gmail.com>
Subject: bug#10149: Emacs 24 hangs for several minutes with very large c++ files
Date: Sat, 2 Nov 2019 10:09:31 +0000	[thread overview]
Message-ID: <20191102100931.GA5738@ACM> (raw)
In-Reply-To: <878sozw5nf.fsf@marxist.se>

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





  parent reply	other threads:[~2019-11-02 10:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-27 23:04 bug#10149: Emacs 24 hangs for several minutes with very large c++ files suvayu ali
2019-11-01 23:14 ` Stefan Kangas
2019-11-02  7:31   ` Eli Zaretskii
2019-11-02 10:09   ` Alan Mackenzie [this message]
2019-11-02 10:31     ` Stefan Kangas
2019-11-02 13:07       ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191102100931.GA5738@ACM \
    --to=acm@muc.de \
    --cc=10149@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=fatkasuvayu+linux@gmail.com \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).