From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jason Rohrer Newsgroups: gmane.emacs.devel Subject: Re: C++-mode indenting performance depends on length of previous function? Date: Sun, 01 Jul 2018 11:26:51 -0700 Message-ID: <1530469611.421476.1426473800.499BD119@webmail.messagingengine.com> References: <1530285651.3874483.1424811480.4B140635@webmail.messagingengine.com> <20180630194703.GD6816@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1530469504 20303 195.159.176.226 (1 Jul 2018 18:25:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 18:25:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 20:25:00 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 1fZh1v-000560-7h for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 20:24:59 +0200 Original-Received: from localhost ([::1]:55244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZh40-000188-Gk for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 14:27:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32869) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZh3r-000182-0i for emacs-devel@gnu.org; Sun, 01 Jul 2018 14:27:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZh3n-0001sQ-1d for emacs-devel@gnu.org; Sun, 01 Jul 2018 14:26:58 -0400 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:48945) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fZh3m-0001ni-Ni for emacs-devel@gnu.org; Sun, 01 Jul 2018 14:26:54 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C2102203 for ; Sun, 1 Jul 2018 14:26:51 -0400 (EDT) Original-Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Sun, 01 Jul 2018 14:26:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=ErSUZ/iZRsEO8ZevIDHMco5K668DF 30eZmst16BZy2I=; b=C41tYgixCOz/Qy4mplV8WiPAf+m38+w0g7e6dv6Uw9WyF iHORnbUL9oFib54D1nE7CuqZcGgdrdcrcxJbqCERt7fRxhdjqu6nB+6z/SOvglL9 WhgRwhEY5c5ZeNf4rxW98Ae6x6JiV3FxPjViZD+4z4pdUBxvKVnYWqvx9JTYGHi+ 2P93lFiitMced+QjKrhTwE+qh8mlLyn8vxCP09Zf250zVOGLuts2cAN2IznS1Rkg t7a8jLcw/8kt3l8vc0i7i+1LcrwMiewOvST+T8Ny9ET2v54p6lG4Bk8vCs9DtC9d Q4hhyENkw0nc7sLDlUKt/EEbTZ2qadudHgZ9ki0XA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ErSUZ/ iZRsEO8ZevIDHMco5K668DF30eZmst16BZy2I=; b=LmhlzqwP0t0tMJEkpvaBkq CTk1halTN59RPz8mVosaQLIV1GYyqKNF3HWi+4cAluDzOJymURWrzTaw5pL7reIh AnnRMv4EGuOJVHGgnt1uWBWRrD+WMraNq8mIWQR/RjTk9PaytYofZ5DDCT4sMYVv FPbp/Lq6TMJX1aKBhTSJo4vsCWek+L1f40F9BYUr1Hnb4qwmintb36Z9JaXDpJf+ L6CB4PnLYeBdbvde29bjJwLkQ21and8KCVhXY5NzQgtoLv/zKy9m4huBgHjgw52T L6pTGnN9OCVs2j64YWQ7uR2knjuOQ/r9RPq7Y9juLCR3gjYFGUz/hre3alxkRaUg == X-ME-Proxy: X-ME-Sender: Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id 195D8621E6; Sun, 1 Jul 2018 14:26:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c In-Reply-To: <20180630194703.GD6816@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.123.20 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:226879 Archived-At: Confirmed that it is fixed in 26.1 Thanks! Jason On Sat, Jun 30, 2018, at 12:47 PM, Alan Mackenzie wrote: > 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).