From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#33670: 26.1; very large c++-mode yank performance regression 25.3_1-x86_64 -> 26.1-x86_64 Date: 8 Dec 2018 20:40:36 -0000 Organization: muc.de e.V. Message-ID: <20181208204036.61878.qmail@mail.muc.de> References: <647599b2-0aae-8654-a662-a8142dd360d2@d6.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1544301551 9588 195.159.176.226 (8 Dec 2018 20:39:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Dec 2018 20:39:11 +0000 (UTC) User-Agent: tin/2.4.2-20171224 ("Lochhead") (UNIX) (FreeBSD/11.2-RELEASE-p4 (amd64)) Cc: 33670@debbugs.gnu.org To: Chris Hecker Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 08 21:39:07 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1gVjNS-0002PW-Tz for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Dec 2018 21:39:07 +0100 Original-Received: from localhost ([::1]:52034 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gVjPZ-0000Xf-MS for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Dec 2018 15:41:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gVjPP-0000XN-Gc for bug-gnu-emacs@gnu.org; Sat, 08 Dec 2018 15:41:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gVjPL-00021X-Eo for bug-gnu-emacs@gnu.org; Sat, 08 Dec 2018 15:41:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34548) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gVjPK-00021O-Ix for bug-gnu-emacs@gnu.org; Sat, 08 Dec 2018 15:41:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gVjPK-0004Ho-Bl for bug-gnu-emacs@gnu.org; Sat, 08 Dec 2018 15:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Dec 2018 20:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33670 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33670-submit@debbugs.gnu.org id=B33670.154430164116424 (code B ref 33670); Sat, 08 Dec 2018 20:41:02 +0000 Original-Received: (at 33670) by debbugs.gnu.org; 8 Dec 2018 20:40:41 +0000 Original-Received: from localhost ([127.0.0.1]:38803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gVjOz-0004Gq-1M for submit@debbugs.gnu.org; Sat, 08 Dec 2018 15:40:41 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:48819 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gVjOv-0004GV-MI for 33670@debbugs.gnu.org; Sat, 08 Dec 2018 15:40:38 -0500 Original-Received: (qmail 61880 invoked by uid 3782); 8 Dec 2018 20:40:36 -0000 In-Reply-To: X-Newsgroups: gnu.emacs.bug X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:153228 Archived-At: Hello, Chris. In article you wrote: > Hi, I recently upgraded from 25.3_1 to to 26.1 on Windows 7 x64 and I've > noticed a very large performance regression on yanks in C++ mode buffers > (it feels slower in many other operations as well, but I actually > measured yank with the profiler). This happens even starting with with > emacs -Q. > If I start emacs and visit a moderately large cpp file (18k LOC), and go > to the same place in the middle of the file in both versions of emacs, > then kill and yank the current line, the performance on 26.1 is easily > 10x worse...the yank is instant in 25.3_1 and takes literally almost a > second on 26.1 sometimes. I decided to test this with a profiler run, > so I went to the same line in both, killed the line, and evaled this: > (progn (profiler-start 'cpu) (yank) (profiler-report) (profiler-stop)) > Here are the results: > 25.3_1: > - ... 1 100% > Automatic GC 1 100% > 26.1: > - command-execute 14 100% > - call-interactively 14 100% > - funcall-interactively 14 100% > - eval-expression 14 100% > - eval 14 100% > - progn 14 100% > - yank 14 100% > - insert-for-yank 14 100% > - insert-for-yank-1 14 100% > - c-after-change 13 92% > - mapc 13 92% > - # 13 92% > - c-after-change-re-mark-raw-strings 6 42% > - c-in-literal 3 21% > - c-state-semi-pp-to-literal 3 21% > c-parse-ps-state-below 3 21% > - c-restore-<>-properties 4 28% > c-syntactic-re-search-forward 4 28% > c-neutralize-syntax-in-CPP 3 21% > - remove-yank-excluded-properties 1 7% > - remove-list-of-text-properties 1 7% > - c-after-change 1 7% > - c-before-change 1 7% > - mapc 1 7% > - # 1 7% > c-depropertize-CPP 1 7% > - ... 0 0% > Automatic GC 0 0% What is this line that you kill, then yank? The profiler report suggests that it has something to do with raw strings, and I wouldn't be at all surprised if the line contains the opening delimiter or closing delimiter of quite a big raw string. > I'm going to try the older cc-mode with the newer emacs and see if that > fixes it, but I figured I'd report this bug now in case you haven't > gotten other reports yet. There was no raw string handling at all in Emacs 25.3, so it is not surprising that CC Mode is much faster, there. When a raw string is started or terminated, CC Mode needs to check, potentially, the rest of the buffer for characters which need "text properties" changing on them. This can be time consuming. However, a change to a line in the inside of a raw string shouldn't be slow, and if it is, that's a bug. > Thanks, > Chris > In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) > of 2018-05-30 built on CIRROCUMULUS > Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea > Windowing system distributor 'Microsoft Corp.', version 6.1.7601 > Recent messages: > For information about GNU Emacs and the GNU system, type C-h C-a. > spyparty_ui.cpp has auto save data; consider M-x recover-this-file > Mark saved where search started > Mark set > Quit > CPU profiler started > Mark set > CPU profiler stopped > "CPU profiler stopped" > C-; is undefined > Quit [3 times] > Configured using: > 'configure --without-dbus --host=x86_64-w64-mingw32 > --without-compress-install 'CFLAGS=-O2 -static -g3'' -- Alan Mackenzie (Nuremberg, Germany).