From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: follow-mode: extremely slow in combination with org-mode Date: Thu, 21 Jun 2018 10:25:39 +0200 Message-ID: References: <87zhzvc9km.fsf@tu-berlin.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000237508056f22a981" X-Trace: blaine.gmane.org 1529569426 18827 195.159.176.226 (21 Jun 2018 08:23:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 21 Jun 2018 08:23:46 +0000 (UTC) Cc: emacs-devel To: Gerald Wildgruber Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 21 10:23: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 1fVusX-0004ls-4R for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2018 10:23:41 +0200 Original-Received: from localhost ([::1]:53745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVuue-0000pR-BG for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2018 04:25:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVuuX-0000pM-3i for emacs-devel@gnu.org; Thu, 21 Jun 2018 04:25:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fVuuV-0003Ah-5b for emacs-devel@gnu.org; Thu, 21 Jun 2018 04:25:45 -0400 Original-Received: from mail-lf0-x22a.google.com ([2a00:1450:4010:c07::22a]:45056) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fVuuU-00038v-O3 for emacs-devel@gnu.org; Thu, 21 Jun 2018 04:25:43 -0400 Original-Received: by mail-lf0-x22a.google.com with SMTP id a13-v6so3412349lfk.12 for ; Thu, 21 Jun 2018 01:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B3Cs9eGk4hvFYGJW4sWETzEycDoO9Ydwpvy6F01RrrE=; b=OpTwB+tfX0kGTiht7d6aVwKoB/H8O1TAsgmTZ7t67psph0Ks8x4jZpvxrr0Fw3PZA7 00H9wRJmqUoY4n5worScwSqpzBhpVBoRTdz9g3c0s0i9QD7wx3XFtcwFHcLBR15QK0Oe cNntJDWgxvHndCmdCl0gtGV9mj97u/kr7pxFEcdA9uq+X24q5UJSP01F0rGAcQm+n9T2 eZuMIpBpsuAjBt3HShn9rWv6p1Ci4gH12c4eJzGvgqN945P0zJYHe7ymnAIIHKTHmr2S D5cLDL43kkw/+2H1nOU1QUTO4njFHpaBh82a+JDtdLsG3cxdumSyLcnTxJ6Wp/yjL9Mh OvXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B3Cs9eGk4hvFYGJW4sWETzEycDoO9Ydwpvy6F01RrrE=; b=QQDIgfcAwvpTUTBJqquj6ciy32OJWAEVs3auaP7wjjLdD2F0MzR5k2VuZiXuUH1x1t eVkd+YrN0sRz/WVAQ9ImYX28+jj8CFPmL1IdLM5YaXdXR2si/eVXh4WSchsMEnEVAhH6 EvNhe4TznbaReRw3tZ2b66Ct7EVTglCVT5I+FjQHCu27ltP7v9wOTaL3juPgtV3hnVYN YQm/Tk6h6cLlMKfYplgDEeh59FzsorcV+LzCgE9TxOA48/B1g0hhkEQ/96zEb8DvtJrE AF78WOR89UPX3FiBFJlQEAYdadW6uVElabJKeaGLRE9CxAwpGuOYZ+9SN8280p/MX4Fo opJw== X-Gm-Message-State: APt69E0NFwX9NZLJiaq1UMcIo8w3B2+zoNA83vDHgccE3FS2NaPFTCmj 5+GkEWEa/Bsfh/J7uH8SuI16BDfxVisTRBPTuZU= X-Google-Smtp-Source: ADUXVKKkGdZ/qRpFqp09ur4lZO0voWVOwPoHN60PLwoaNDNLEJXYJ99XwkUCPIG0fRBPBtJYbrvlYuJS9MLp8wCz3bk= X-Received: by 2002:a19:e4d2:: with SMTP id x79-v6mr934980lfi.76.1529569540796; Thu, 21 Jun 2018 01:25:40 -0700 (PDT) Original-Received: by 2002:a19:d054:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 01:25:39 -0700 (PDT) In-Reply-To: <87zhzvc9km.fsf@tu-berlin.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22a 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:226561 Archived-At: --000000000000237508056f22a981 Content-Type: text/plain; charset="UTF-8" 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 more 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. 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.) - 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 try if and see if follow-mode runs more smoothly. 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 layout, 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, but I'm happy to share my ideas if someone else is willing to make a try. 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. 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 47% > + follow-post-command-hook 7755 41% > + ... 1976 10% > + 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 41% > - follow-adjust-window 7755 41% > - follow-windows-start-end 7732 41% > - follow-calc-win-end 7732 41% > + 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 > > --000000000000237508056f22a981 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

There can be a number of reasons why follow-mode is slo= w. The main problem is that is it's time consuming to recompute the win= dow state, and even more time consuming when aligning the windows. For simp= le commands like point movement, follow-mode assumes that the content of th= e buffers hasn't changed and retain the existing layout, whereas for ot= her commands (including self-insert-command), everything is recomputed and = realigned.

However, I use si= x side by side windows, and a small font, giving me a total of almost 800 c= onsecutive lines, and it typically runs fine without any noticeable lag.

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 bin= ary (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 a= vailable.)

- Follow-mode is = has problems when the width of the windows differ, especially if you have l= ong lines that spill over from one window to another. I've written a su= pport package to set up side-by-side windows in a pixel-perfect way,=C2=A0<= a href=3D"https://github.com/Lindydancer/multicolumn">https://github.com/Li= ndydancer/multicolumn -- please try if and see if follow-mode runs more= smoothly.

One thing that I = have had on my wish-list for a very long time (20+ years) is that normal ty= ping should use and update the cache, to speed things up. Of course, this o= nly work as long as the editing doesn't change the layout, like when in= serting a newline or make a line so long that it wraps. Unfortunately, I do= n't think that I will have time for it anytime soon, but I'm happy = to share my ideas if someone else is willing to make a try.

What made me curious that you said th= at the slow-down only occurs with org-mode. My guess is that invisible text= makes it harder for Emacs to calculate window layout properties.

Sincerely,
=C2=A0 =C2=A0 Anders Lindgren (I wrote follow-mode when I was a stude= nt, in the mid 1990:s)


On Sat,= Jun 16, 2018 at 12:25 PM, Gerald Wildgruber <wildgruber@tu-berlin.= de> 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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8789=C2=A0 47%
+ follow-post-command-hook=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A07755=C2=A0 41%
+ ...=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1976=C2= =A0 10%
+ redisplay_internal (C function)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0104=C2=A0 =C2=A00%
+ yas--post-command-handler=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 40=C2=A0 =C2=A00%
+ timer-event-handler=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20=C2=A0 =C2=A00%
=C2=A0 tooltip-hide=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7=C2=A0 =C2=A00= %


And somewhat expanded:

- follow-post-command-hook=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A07755=C2=A0 41%
=C2=A0- follow-adjust-window=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 7755=C2=A0 41%
=C2=A0 - follow-windows-start-end=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A07732=C2=A0 41%
=C2=A0 =C2=A0- follow-calc-win-end=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07732=C2=A0 41%
=C2=A0 =C2=A0 + pos-visible-in-window-p=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 25=C2=A0 =C2=A00%
=C2=A0 =C2=A0 + posn-at-x-y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07=C2=A0 =C2=A00%=
=C2=A0 =C2=A0 + window-inside-pixel-edges=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A00%
=C2=A0 + follow-all-followers=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4=C2=A0 =C2=A00%
=C2=A0 =C2=A0 follow-avoid-tail-recenter=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A00%

If I understand correctly "follow-calc-win-end" would be the func= tion
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-h= ook" 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 ther= e
possible optimizations with this situation? Or is this "normal",<= br> expected behavior, simply due to the number of windows and text
displayed?

Thanks

Gerald.

---------------------
Sent with mu4e


--000000000000237508056f22a981--