all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Anders Lindgren <andlind@gmail.com>
To: Gerald Wildgruber <wildgruber@tu-berlin.de>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: follow-mode: extremely slow in combination with org-mode
Date: Thu, 21 Jun 2018 10:25:39 +0200	[thread overview]
Message-ID: <CABr8ebYkjjNVB_96BECOisTWExS+wsDe5ELns=c0hP58F2gOKA@mail.gmail.com> (raw)
In-Reply-To: <87zhzvc9km.fsf@tu-berlin.de>

[-- Attachment #1: Type: text/plain, Size: 5178 bytes --]

 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 <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                                                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
>
>

[-- Attachment #2: Type: text/html, Size: 8166 bytes --]

  parent reply	other threads:[~2018-06-21  8:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-16 10:25 follow-mode: extremely slow in combination with org-mode Gerald Wildgruber
2018-06-16 11:41 ` Eli Zaretskii
2018-06-16 13:06   ` Gerald Wildgruber
2018-06-16 16:25     ` Eli Zaretskii
2018-06-16 21:05       ` Gerald Wildgruber
2018-06-17  6:57       ` Gerald Wildgruber
2018-06-17  8:12         ` Eli Zaretskii
2018-06-17 11:13           ` Alan Mackenzie
2018-06-17 13:02             ` Eli Zaretskii
2018-06-17 14:56               ` Gerald Wildgruber
2018-06-17 15:10                 ` Eli Zaretskii
2018-06-19 12:08                   ` Gerald Wildgruber
2018-06-19 16:55                     ` Eli Zaretskii
2018-06-19 13:53                   ` Gerald Wildgruber
2018-06-17 15:13             ` Eli Zaretskii
2018-06-21  8:25 ` Anders Lindgren [this message]
2018-06-27 16:43   ` Gerald Wildgruber
2018-07-09 20:12     ` Anders Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABr8ebYkjjNVB_96BECOisTWExS+wsDe5ELns=c0hP58F2gOKA@mail.gmail.com' \
    --to=andlind@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=wildgruber@tu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.