From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23327: 25.0.92; show-trailing-whitespace uses too much cpu Date: Thu, 21 Apr 2016 17:16:08 +0300 Message-ID: <837ffr6o9j.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1461248249 5399 80.91.229.3 (21 Apr 2016 14:17:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Apr 2016 14:17:29 +0000 (UTC) Cc: 23327@debbugs.gnu.org To: Mohammed Sadik Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 21 16:17:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1atFPv-00056x-ME for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Apr 2016 16:17:15 +0200 Original-Received: from localhost ([::1]:41959 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atFPq-0002TJ-R2 for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Apr 2016 10:17:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atFPm-0002Q5-9u for bug-gnu-emacs@gnu.org; Thu, 21 Apr 2016 10:17:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atFPi-0002AV-4F for bug-gnu-emacs@gnu.org; Thu, 21 Apr 2016 10:17:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atFPi-0002AL-1G for bug-gnu-emacs@gnu.org; Thu, 21 Apr 2016 10:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1atFPh-00030m-Tm for bug-gnu-emacs@gnu.org; Thu, 21 Apr 2016 10:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Apr 2016 14:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23327 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23327-submit@debbugs.gnu.org id=B23327.146124818411529 (code B ref 23327); Thu, 21 Apr 2016 14:17:01 +0000 Original-Received: (at 23327) by debbugs.gnu.org; 21 Apr 2016 14:16:24 +0000 Original-Received: from localhost ([127.0.0.1]:42447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atFP6-0002zt-IN for submit@debbugs.gnu.org; Thu, 21 Apr 2016 10:16:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atFP4-0002zd-GB for 23327@debbugs.gnu.org; Thu, 21 Apr 2016 10:16:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atFOw-00020z-2K for 23327@debbugs.gnu.org; Thu, 21 Apr 2016 10:16:17 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atFOv-00020u-Uz; Thu, 21 Apr 2016 10:16:13 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4740 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1atFOv-0006wl-8g; Thu, 21 Apr 2016 10:16:13 -0400 In-reply-to: (message from Mohammed Sadik on Thu, 21 Apr 2016 11:33:55 +0530) 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:116648 Archived-At: > Date: Thu, 21 Apr 2016 11:33:55 +0530 > From: Mohammed Sadik > > Enabling show-trailing-whitespace and navigating through buffer uses too > much CPU. An increase of about 4-6% of CPU on my 2.4 GHz Quad-core > system. > > How to reproduce: > > 1. Open a large source code file (I opened cc-engine.el from Emacs source). > 2. Enable show-trailing-whitespace (setq show-trailing-whitespace t) > 3. Press and hold the arrow keys to navigate. See the processor usage > (use top/htop or similar program). > 4. Now disable show-trailing-whitespace (setq show-trailing-whitespace > nil) > 5. Repeat 3 > > This also happens when pressing any other key (eg:while typing). The Emacs display engine employs several aggressive optimizations for simple operations like cursor motion and inserting a single character. When you turn on show-trailing-whitespace, most of these optimizations are disabled, so it's very small wonder that redisplay becomes more expensive. The reason that these optimizations are disable is this feature of show-trailing-whitespace: This feature does not apply when point is at the end of the line containing the whitespace. Strictly speaking, that is trailing whitespace nonetheless, but displaying it specially in that case looks ugly while you are typing in new text. In this special case, the location of point is enough to show you that the spaces are present. Because of this, when you move the cursor, the display engine cannot assume that the display remains unchanged, because it needs to see if the cursor happens to be after a stretch of trailing whitespace, in which case, that whole stretch of whitespace needs to be redrawn as well. For the same reason, other optimizations, like those which reuse portions of the previously displayed window, are abandoned. I've looked at the optimizations we disable in this case, and I cannot see anything wrong in those decisions, given the way this feature works. We could try adding an optional feature which doesn't turn off the special display of trailing whitespace when the cursor is at the end of a line that ends in whitespace, that might allow us to re-enable these optimizations. Would users like that? Other than that, I don't see how this could be helped, except by some thorough redesign of how this feature works. I don't immediately see how to do that, but maybe someone else does, and is motivated to work on this. > Also this creates minor glitches in displaying text on buffer > (sudden disappearance and appearence of some text) when CPU is already > enough busy. If your CPU is very busy, then adding a few percents to it might indeed produce such jerky redisplay, I think.