From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#29889: 27.0.50; Slow visual selection Date: Sun, 31 Dec 2017 20:43:47 +0200 Message-ID: <831sjaeo0s.fsf@gnu.org> References: <87y3lmgphl.fsf@gmail.com> <83tvw9gb26.fsf@gnu.org> <87efndro8q.fsf@gmail.com> <837et4fraf.fsf@gnu.org> <87wp13h3jn.fsf@gmail.com> <724A6161-783D-4CAD-AFBD-40D6AEF2C6E6@gnu.org> <87incnqoeo.fsf@gmail.com> <83h8s6ewmn.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1514745797 13724 195.159.176.226 (31 Dec 2017 18:43:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Dec 2017 18:43:17 +0000 (UTC) Cc: 29889@debbugs.gnu.org To: m.sujith@gmail.com, Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 31 19:43:13 2017 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 1eViZk-0003Mt-So for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Dec 2017 19:43:12 +0100 Original-Received: from localhost ([::1]:48342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eVibj-0004MS-TR for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Dec 2017 13:45:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eVibb-0004Jp-W4 for bug-gnu-emacs@gnu.org; Sun, 31 Dec 2017 13:45:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eVibX-00055c-4j for bug-gnu-emacs@gnu.org; Sun, 31 Dec 2017 13:45:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50326) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eVibX-00055Q-0M for bug-gnu-emacs@gnu.org; Sun, 31 Dec 2017 13:45:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eVibW-0006nB-Kf for bug-gnu-emacs@gnu.org; Sun, 31 Dec 2017 13:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Dec 2017 18:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29889 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29889-submit@debbugs.gnu.org id=B29889.151474584926016 (code B ref 29889); Sun, 31 Dec 2017 18:45:02 +0000 Original-Received: (at 29889) by debbugs.gnu.org; 31 Dec 2017 18:44:09 +0000 Original-Received: from localhost ([127.0.0.1]:59007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eViaf-0006lY-5T for submit@debbugs.gnu.org; Sun, 31 Dec 2017 13:44:09 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60991) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eViad-0006lK-W3 for 29889@debbugs.gnu.org; Sun, 31 Dec 2017 13:44:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eViaT-0004cQ-LS for 29889@debbugs.gnu.org; Sun, 31 Dec 2017 13:44:02 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eViaT-0004cJ-Hs; Sun, 31 Dec 2017 13:43:57 -0500 Original-Received: from [176.228.60.248] (port=2727 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eViaS-0002Cb-Vz; Sun, 31 Dec 2017 13:43:57 -0500 In-reply-to: <83h8s6ewmn.fsf@gnu.org> (message from Eli Zaretskii on Sun, 31 Dec 2017 17:37:52 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:141656 Archived-At: > Date: Sun, 31 Dec 2017 17:37:52 +0200 > From: Eli Zaretskii > Cc: 29889@debbugs.gnu.org > > > After doing (setq gc-cons-threshold 1000000000), the issue doesn't > > seem to happen. The cursor moved around freely except for one > > interruption - maybe the GC kicked in then. > > Oh, you are right: if I set garbage-collection-messages non-nil, I see > a GC message each time I move the cursor. > > So I guess my original theory was probably wrong, and the actual > suspect is some code, yet to be discovered, that conses such large > amounts of Lisp data. I will look into it if no one beats me to it. Long story short: set select-active-regions to 'only' or nil, and the problem goes away. Here's what happens: select-active-regions is now t by default, since Emacs 24.1. When that variable is t, every command, except those in the list selection-inhibit-update-commands (a variable that is not documented in any manual, btw), causes us to set the primary X selection with the text in the active region. Doing that invokes the value of region-extract-function, which makes a string out of the active region, which in this case is the entire buffer text. For a large buffer, such as vhdl.el, this conses a large string, thus triggering GC _on_every_keystroke_. And that _does_ make Emacs slow. To add insult to injury, region-extract-function calls buffer-substring--filter, which calls buffer-substring. In a buffer with a lot of text properties, such as the one that is fully fontified, this involves copying the properties from the buffer to the newly created string, most probably just to remove the properties right after that (because the X selection doesn't need them). Which explains why a fully fontified buffer made things even more slow. So how do we resolve this issue? Should we set select-active-regions to 'only' by default? Should we arrange for region-extract-function to call buffer-substring-no-properties instead, at least in this specific use case? Should we do both? Something else?