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: Wed, 27 Jun 2018 18:43:07 +0200 Message-ID: <87o9fwkwo4.fsf@tu-berlin.de> References: <87zhzvc9km.fsf@tu-berlin.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1530117976 15476 195.159.176.226 (27 Jun 2018 16:46:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Jun 2018 16:46:16 +0000 (UTC) User-Agent: mu4e 1.1.0; emacs 27.0.50 Cc: emacs-devel To: Anders Lindgren Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 27 18:46:11 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 1fYDa3-0003rP-Tj for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2018 18:46:08 +0200 Original-Received: from localhost ([::1]:60469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYDcB-000509-5v for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2018 12:48:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYDYJ-0001zO-QN for emacs-devel@gnu.org; Wed, 27 Jun 2018 12:44:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYDYF-0002sZ-Nr for emacs-devel@gnu.org; Wed, 27 Jun 2018 12:44:19 -0400 Original-Received: from exchange.tu-berlin.de ([130.149.7.70]:65009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYDYF-0002ph-91 for emacs-devel@gnu.org; Wed, 27 Jun 2018 12:44:15 -0400 Original-Received: from SPMA-01.tubit.win.tu-berlin.de (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 20D1A7DDC34_B33BEDAB; Wed, 27 Jun 2018 16:44:10 +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-01.tubit.win.tu-berlin.de (Sophos Email Appliance) with ESMTPS id D5FB57DD9D9_B33BED8F; Wed, 27 Jun 2018 16:44:08 +0000 (GMT) Original-Received: from krios (130.149.43.226) by ex-mbx-10.tubit.win.tu-berlin.de (130.149.6.164) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 27 Jun 2018 18:44:08 +0200 In-Reply-To: X-ClientProxiedBy: EX-MBX05.tubit.win.tu-berlin.de (130.149.6.149) 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.52 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:226788 Archived-At: Hi Anders thanks for your reply: I just returned to office and couldn't answer earlier! On Do, Jun 21 2018, Anders Lindgren wrote: > Hi! > > There can be a number of reasons why follow-mode is slow. The main problem > is that is it's time consuming to recompute the window state, and even mo= re > time consuming when aligning the windows. For simple commands like point > movement, follow-mode assumes that the content of the buffers hasn't > changed and retain the existing layout, whereas for other commands > (including self-insert-command), everything is recomputed and realigned. > > However, I use six side by side windows, and a small font, giving me a > total of almost 800 consecutive lines, and it typically runs fine without > any noticeable lag. That's quite close to my setup. However: when I use org-mode, with entire branches collapsed, there might well be several thousand (2000-15000) lines of text in the buffer; if all this is recalculated every time I enter a letter, -- perhaps the lags I observe are "normal". But then, the machine I'm working on is a really fast and new computer. > There are a number of factors that can have a negative impact on > follow-mode: > - It run slower on a 32 bit binary than on a 64 bit binary (at least under > Windows). (For this reason, I used Emacs 22 at work for many years, until > prebuilt 64 bit binaries of modern Emacs versions were available.) Mine are 64 bit machines. > - Follow-mode is has problems when the width of the windows differ, > especially if you have long lines that spill over from one window to > another. I've written a support package to set up side-by-side windows in= a > pixel-perfect way, https://github.com/Lindydancer/multicolumn -- please t= ry > if and see if follow-mode runs more smoothly. Actually I use this already! I have in my .emacs the following: (require 'multicolumn) (multicolumn-global-mode 1) > One thing that I have had on my wish-list for a very long time (20+ years) > is that normal typing should use and update the cache, to speed things up. > Of course, this only work as long as the editing doesn't change the layou= t, > like when inserting a newline or make a line so long that it wraps. > Unfortunately, I don't think that I will have time for it anytime soon, b= ut > I'm happy to share my ideas if someone else is willing to make a try. I hope someone picks this up!!! :-) Can you tell if the function that uses so much of cpu time -- follow-calc-win-end -- in the form it is now part of new emacs versions, has any evident problem compared to your own longer version in pre version 22 emacs? Cf Alan's posting in this thread: https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00522.html > What made me curious that you said that the slow-down only occurs with > org-mode. My guess is that invisible text makes it harder for Emacs to > calculate window layout properties. Yes: the lag is much lower with text-mode. Thanks again Gerald. > Sincerely, > Anders Lindgren (I wrote follow-mode when I was a student, in the mid > 1990:s) > > > On Sat, Jun 16, 2018 at 12:25 PM, Gerald Wildgruber > wrote: > >> >> Hi, >> >> I have got a problem with enormous lag while entering text in buffers >> with emacs follow-mode enabled. >> >> I'm using emacs (git checkout v. 27.0.50) and Org mode (git checkout >> release_9.1.13-760-g8def68). >> >> My work is solely text-based, using org-mode. A typical setup is to use >> a maximized or full screen emacs frame split into five windows >> positioned vertically one next to the other on a 40" 4k display. All >> five windows display one and the same file, that is opened using emacs >> follow-mode, so that every window is displaying a portion of the same >> file in a continuous manner (simultaneously displaying up to 45kb of >> text in one frame, an entire paper). >> >> Unfortunately, with this setup there is terrible lag with every single >> key input (on a very fast quad core machine); every key stroke produces >> a 100% processor load. >> >> If I deactivate follow-mode, the problem disappears. It also gets better >> if I enable text-mode instead of org-mode. >> >> I then used the elisp profiler (M-x profiler-start/report) to find out >> which function uses most cpu time while editing text in said setup. Here >> is the result: >> >> Collapsed, the report looks like that: >> >> + command-execute 8789 4= 7% >> + follow-post-command-hook 7755 4= 1% >> + ... 1976 1= 0% >> + redisplay_internal (C function) 104 = 0% >> + yas--post-command-handler 40 = 0% >> + timer-event-handler 20 = 0% >> tooltip-hide 7 = 0% >> >> >> And somewhat expanded: >> >> - follow-post-command-hook 7755 4= 1% >> - follow-adjust-window 7755 4= 1% >> - follow-windows-start-end 7732 4= 1% >> - follow-calc-win-end 7732 4= 1% >> + pos-visible-in-window-p 25 = 0% >> + posn-at-x-y 7 = 0% >> + window-inside-pixel-edges 3 = 0% >> + follow-all-followers 4 = 0% >> follow-avoid-tail-recenter 3 = 0% >> >> If I understand correctly "follow-calc-win-end" would be the function >> that uses most of cpu time. >> >> I then did additional profiling with the elp library, adding relevant >> functions under "Command-execute" and "follow-post-command-hook" to >> elp-function-list, edited text, and then did M-x elp-results. It showed >> again that "follow-calc-win-end" by far used most of cpu time. >> >> Anyone got an idea what's going on here and how to debug that? Are there >> possible optimizations with this situation? Or is this "normal", >> expected behavior, simply due to the number of windows and text >> displayed? >> >> Thanks >> >> Gerald. >> >> --------------------- >> Sent with mu4e >> >> -- Dr. Gerald Wildgruber Institut f=C3=BCr Philosophie, Literatur-, Wissenschafts- und Technikgeschi= chte Literaturwissenschaft mit Schwerpunkt Literatur und Wissenschaft Technische Universit=C3=A4t Berlin Stra=C3=9Fe des 17. Juni 135 D-10623 Berlin http://www.philosophie.tu-berlin.de/menue/home/ T. +49 (0)30 314 25924 F. +49 (0)30 314 23107 wildgruber@tu-berlin.de --------------------- Sent with mu4e