From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: C++-mode indenting performance depends on length of previous function? Date: Sat, 30 Jun 2018 19:47:03 +0000 Message-ID: <20180630194703.GD6816@ACM> References: <1530285651.3874483.1424811480.4B140635@webmail.messagingengine.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1530388489 30996 195.159.176.226 (30 Jun 2018 19:54:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Jun 2018 19:54:49 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: emacs-devel@gnu.org To: Jason Rohrer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 30 21:54:45 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fZLxE-0007yC-Fe for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 21:54:45 +0200 Original-Received: from localhost ([::1]:47830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZLzL-0005xl-FF for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 15:56:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZLyk-0005xb-7Q for emacs-devel@gnu.org; Sat, 30 Jun 2018 15:56:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZLyh-0005BB-6e for emacs-devel@gnu.org; Sat, 30 Jun 2018 15:56:18 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:29121 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fZLyg-0005AF-Us for emacs-devel@gnu.org; Sat, 30 Jun 2018 15:56:15 -0400 Original-Received: (qmail 12703 invoked by uid 3782); 30 Jun 2018 19:56:13 -0000 Original-Received: from acm.muc.de (p5B147D93.dip0.t-ipconnect.de [91.20.125.147]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 30 Jun 2018 21:56:12 +0200 Original-Received: (qmail 10133 invoked by uid 1000); 30 Jun 2018 19:47:03 -0000 Content-Disposition: inline In-Reply-To: <1530285651.3874483.1424811480.4B140635@webmail.messagingengine.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226853 Archived-At: Hello, Jason. Thanks for the report. Thanks even more for making your source file so easily available, thus making it very easy for me to try things out. On Fri, Jun 29, 2018 at 08:20:51 -0700, Jason Rohrer wrote: > Tested in Emacs 23, 24, and 25. Same behavior with or without > font-lock-mode, and linum-mode is off. I think the problem is fixed in Emacs 26.1. This was released a little over a month ago. > I have a 6000-line C++ function with a bunch of internal nesting. I > would expect auto-indenting to be a bit slow inside this function, but > it turns out that it mostly is not slow, especially inside sub-blocks > of the giant function (inside the top-level block, it is a bit slow). I did an hg bisection on the CC Mode sources, and the git commit which seems to have serendipitously fixed the bug is: commit 59d07875df9d44568d93a7517853e6a5ccaf1e5b Author: Alan Mackenzie Date: Sat Jul 1 15:43:07 2017 +0000 Make C++ digit separators work. Amend the handling of single quotes generally > However, I'm seeing enormous slow-down when creating sub-blocks inside > the NEXT function, even if it is a short function. Both functions are > top-level blocks with 0-indent, but it seems like the auto-indent and > auto-bracket stuff is scanning the previous function for some reason. > And, unlike the good performance inside sub-blocks of the huge > function, I'm seeing slow performance in sub-blocks and sub-sub-blocks > of the next function. Nesting doesn't seem to change anything... It > must still be scanning the previous function block entirely for some > reason. If I put a tiny dummy function in between, the dummy function > is slow to edit, but the next function is fast again. I saw the slowness too, on Emacs 25.3. On my machine (which isn't by any means slow) there were pauses of, perhaps 0.5s when CC Mode had to indent things, in your tiny "workaround" function. Again, could you please try out Emacs 26.1 [ .... ] > The live code in question is here: > https://github.com/jasonrohrer/OneLife/blob/master/gameSource/LivingLifePage.cpp :-) > Grep for "dummyFunctionA" and then try adding some new blocks inside > that function. Since it's the function after the gigantic ::step > function, editing it is slow. But the next function, ::makeActive, is > fast to edit. > Leaving dummyFunctionA in place is my current work-around. Otherwise, > makeActive is simply too slow/frustrating to edit. > (And before you tell me to re-factor the big function, I have my > reasons---it's a game loop---and "emacs can't handle it" shouldn't be > a driving reason to re-factor.) As maintainer of CC Mode, I've seen far worse (like a 6,000 line long macro). :-( > Anyone know what's going on here? > Why does the previous top-level block matter? Why doesn't it stop > scanning backward when it hits the beginning of the current top-level > block? I'm speculating, but sometimes it matters whether or not a brace pair is at the top level, particularly in such a complicated language as C++. With a long function this can take a long time to determine. Yet again, would you please see if you agree with me that the bug has been fixed in Emacs 26.1. If there are still unacceptable pauses, I'll take a more detailed look at the problem. Thanks! > Jason -- Alan Mackenzie (Nuremberg, Germany).