From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gerald Wildgruber Newsgroups: gmane.emacs.devel Subject: Re: follow-mode: extremely slow in combination with org-mode Date: Sun, 17 Jun 2018 16:56:00 +0200 Message-ID: <87tvq1qx6n.fsf@tu-berlin.de> References: <87zhzvc9km.fsf@tu-berlin.de> <83r2l7yn52.fsf@gnu.org> <87y3fedgnq.fsf@tu-berlin.de> <838t7ezokb.fsf@gnu.org> <877emx3not.fsf@tu-berlin.de> <83lgbdu8zs.fsf@gnu.org> <20180617111333.GA12093@ACM> <83k1qxtvkt.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1529247286 23392 195.159.176.226 (17 Jun 2018 14:54:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 17 Jun 2018 14:54:46 +0000 (UTC) User-Agent: mu4e 1.1.0; emacs 27.0.50 Cc: Alan Mackenzie , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 17 16:54:42 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 1fUZ4i-00060K-PD for ged-emacs-devel@m.gmane.org; Sun, 17 Jun 2018 16:54:41 +0200 Original-Received: from localhost ([::1]:55524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUZ6p-0003vz-Rt for ged-emacs-devel@m.gmane.org; Sun, 17 Jun 2018 10:56:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUZ6C-0003vi-So for emacs-devel@gnu.org; Sun, 17 Jun 2018 10:56:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUZ6B-0004DE-KQ for emacs-devel@gnu.org; Sun, 17 Jun 2018 10:56:12 -0400 Original-Received: from exchange.tu-berlin.de ([130.149.7.70]:30234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUZ65-00046g-M4; Sun, 17 Jun 2018 10:56:06 -0400 Original-Received: from SPMA-04.tubit.win.tu-berlin.de (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id DAB86972471_B267682B; Sun, 17 Jun 2018 14:56:02 +0000 (GMT) Original-Received: from exchange.tu-berlin.de (exchange.tu-berlin.de [130.149.7.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "exchange.tu-berlin.de", Issuer "DFN-Verein Global Issuing CA" (not verified)) by SPMA-04.tubit.win.tu-berlin.de (Sophos Email Appliance) with ESMTPS id 18EFC96FDAE_B267682F; Sun, 17 Jun 2018 14:56:02 +0000 (GMT) Original-Received: from corax (178.199.231.181) by ex-mbx-10.tubit.win.tu-berlin.de (130.149.6.164) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 17 Jun 2018 16:56:01 +0200 In-Reply-To: <83k1qxtvkt.fsf@gnu.org> X-ClientProxiedBy: EX-CAS-02.tubit.win.tu-berlin.de (130.149.6.79) To ex-mbx-10.tubit.win.tu-berlin.de (130.149.6.164) X-PMWin-Version: 4.0.1, Antivirus-Engine: 3.72.1, Antivirus-Data: 5.51 X-PureMessage: [Scanned] X-SASI-RCODE: 200 X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x [fuzzy] X-Received-From: 130.149.7.70 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:226409 Archived-At: Thanks again Eli and Alan for picking this up! Eli: the patch didn't apply cleanly (with "patch -p1 <" or "git apply"), but as it is so simple I applied it manually. follow-calc-win-end now looks like that: ================================================== (defun follow-calc-win-end (&optional win) "Calculate the end position for window WIN. Return (END-POS END-OF-BUFFER). Actually, the position returned is the start of the line after the last fully-visible line in WIN. END-OF-BUFFER is t when EOB is fully-visible in WIN. If WIN is nil, the selected window is used." (or win (setq win (selected-window))) (with-selected-window win (let* ((wend (window-end win t)) (endp (= wend (point-max)))) (and (> wend (point-min)) (setq wend (1- wend))) (setq wend (save-excursion (goto-char wend) (line-beginning-position))) (list wend endp)))) ================================================== I byte compiled the patched follow.el restarted emacs and began editing. It actually seems somewhat faster, though not enormously; I will continue working with this patched version to see how it goes; I have a more problematic (=slower) machine in my office, and I'm am eager to see, if it makes a difference there; at home, where I'm testing right now, its a new quad core xeon with 64gb of ram, -- and it is kind of strange that with such a machine fans start very audibly as soon as you start TYPING (not video editing or the like) :-) One more observation: it might be that the slowing down becomes more noticeable, the closer point gets to the bottom of the last window (lower right edge of my five-fold splitted emacs frame), but I couldn't reproduce this consistently. Please count on me for any other testing that might be necessary! I'm no programmer but will do my best to deliver usable results. Here's how the profile looks now, with the patched, uncompiled follow.el loaded right before profiling: - follow-post-command-hook 17642 40% - if 17642 40% - let 17642 40% - save-current-buffer 17642 40% - follow-adjust-window 17642 40% - if 17642 40% - progn 17642 40% - let 17591 40% - let* 17560 40% - progn 16733 38% - follow-windows-start-end 16730 38% - if 16730 38% - let 16730 38% - let 16730 38% - while 16730 38% - setq 16719 38% - cons 16564 37% - cons 16560 37% - cons 16560 37% - follow-calc-win-end 16557 37% - let 16557 37% - save-current-buffer 16557 37% - unwind-protect 16557 37% - progn 16551 37% let* 16548 37% internal--after-with-selected-window 3 0% + follow-windows-start-end 155 0% + if 827 1% + follow-all-followers 27 0% + follow-avoid-tail-recenter 51 0% + command-execute 17015 38% Gerald. On So, Jun 17 2018, Eli Zaretskii wrote: > Gerald, could you try the following patch to follow-calc-win-end? > Please first see if this makes it significantly faster in your use > cases, and if so, please run with it for a while and see if there are > some adverse effects. (If this is not faster, it isn't worth testing > it more.) > > diff --git a/lisp/follow.el b/lisp/follow.el > index fd397c0..c99fc93 100644 > --- a/lisp/follow.el > +++ b/lisp/follow.el > @@ -925,14 +925,17 @@ follow-calc-win-end > the last fully-visible line in WIN. END-OF-BUFFER is t when EOB > is fully-visible in WIN. If WIN is nil, the selected window is > used." > - (let* ((win (or win (selected-window))) > - (edges (window-inside-pixel-edges win)) > - (ht (- (nth 3 edges) (nth 1 edges))) > - (last-line-pos (posn-point (posn-at-x-y 0 (1- ht) win)))) > - (if (pos-visible-in-window-p last-line-pos win) > - (let ((end (window-end win t))) > - (list end (pos-visible-in-window-p (point-max) win))) > - (list last-line-pos nil)))) > + (or win (setq win (selected-window))) > + (with-selected-window win > + (let* ((wend (window-end win t)) > + (endp (= wend (point-max)))) > + (and (> wend (point-min)) > + (setq wend (1- wend))) > + (setq wend > + (save-excursion > + (goto-char wend) > + (line-beginning-position))) > + (list wend endp)))) > > (defun follow-calc-win-start (windows pos win) > "Determine the start of window WIN in a Follow mode window chain. --------------------- Sent with mu4e