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: C++-mode indenting performance depends on length of previous function? Date: Fri, 29 Jun 2018 08:20:51 -0700 Message-ID: <1530285651.3874483.1424811480.4B140635@webmail.messagingengine.com> 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 1530288594 19039 195.159.176.226 (29 Jun 2018 16:09:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 29 Jun 2018 16:09:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 29 18:09:49 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 1fYvxz-0004q2-Qy for ged-emacs-devel@m.gmane.org; Fri, 29 Jun 2018 18:09:48 +0200 Original-Received: from localhost ([::1]:43260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYw07-0006DD-7H for ged-emacs-devel@m.gmane.org; Fri, 29 Jun 2018 12:11:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYvCk-0005mY-F4 for emacs-devel@gnu.org; Fri, 29 Jun 2018 11:21:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYvCf-00088B-T0 for emacs-devel@gnu.org; Fri, 29 Jun 2018 11:20:58 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:37561) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fYvCf-00084g-Me for emacs-devel@gnu.org; Fri, 29 Jun 2018 11:20:53 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DD40A21BFD for ; Fri, 29 Jun 2018 11:20:51 -0400 (EDT) Original-Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Fri, 29 Jun 2018 11:20:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=FedezD7tLiT1Lh79rbFMffycMZ5rzC8TyYcZcni63aM=; b=UDNSiMbv GN2Smb5kiwd/K7YFtDcKbwIvE5JqeoldJE2tvVo9NLWxVCTVEKTc7oiBeaLRb1mU q1twl1r1ZozS0d8kIw6noDSBFckcoABi4wA3DfyFyEznzzKz+AMilmvrN4K6kEEQ 2esVGRDZe4pyGxsVkHc6QWmvlpQTJrVQVNf38kevpx9+0aUra5OJRXwWMl0rj1fX z23bH84gM6Y7ONJJ0Re02YxqFhNPNgM23IX2Xo0qynrJQ3xy4MHIYgvnbuWmM5EM 3Thw9eucbFeEY+pyN2qrfBIdfo/pqmKtnIk2TJ3pqcuvzpMQ84hOdUj/dcU56tBB 2S9XFDw3GLfOPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=FedezD7tLiT1Lh79rbFMffycMZ5rz C8TyYcZcni63aM=; b=GdCbJ/GjxfD9Et2TDeNwyxeNzjD/ypMQHJnGtVyy/zmIr 5WPdJLaBRA8KvUT6xuWpN8TKolDSGT5JlnE2j1crOHC2YeAXbb7m/N/U7nGn2Dnu c33aA4Zt11I7XIg7UhxBAPBYOIckMvp8+Rjcz4+CKrdNc3txiuEVOd6kEYXFwtCL 6urZpMhwWu9FOFrJWeAoAgPBlpg8kzUAaY1ggoKya4Zcn3GYxXbdv/PWBabmJHKS u4Mw6dxPIY2EuAkMjEjEPunVi+utSz6kquCLJjN1CtN3al+B9UYezWoTgtDJxNc8 mcQyBZADdusBJqL/4GAP//JK2gs/JGRNkmj9LVjpA== X-ME-Proxy: X-ME-Sender: Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id 91EFD432C; Fri, 29 Jun 2018 11:20:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.111.4.25 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:226832 Archived-At: Tested in Emacs 23, 24, and 25. Same behavior with or without font-lock-mode, and linum-mode is off. 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). 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. void longComplicatedFunction() { // imagine 6000 lines here } void anotherShorterFunction() { // very slow to edit this } But with the dummy function in between, I see: void longComplicatedFunction() { // imagine 6000 lines here } void dummyFunction() { // very slow to edit this, now } void anotherShorterFunction() { // fast editing, back to normal } Profiler shows that electric-brace and electric-paren are to blame: - command-execute 18219 99% - call-interactively 18217 99% + c-electric-brace 11417 62% + c-electric-paren 2562 14% + c-indent-line-or-region 2223 12% + newline 1927 10% + self-insert-command 42 0% + minibuffer-complete 18 0% + execute-extended-command 9 0% + c-electric-backspace 7 0% + byte-code 7 0% + previous-line 5 0% + ... 21 0% + redisplay_internal (C function) 4 0% + timer-event-handler 2 0% 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.) 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? Jason