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: follow-mode: extremely slow in combination with org-mode Date: Sat, 16 Jun 2018 12:25:13 +0200 Message-ID: <87zhzvc9km.fsf@tu-berlin.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1529144644 18680 195.159.176.226 (16 Jun 2018 10:24:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2018 10:24:04 +0000 (UTC) User-Agent: mu4e 1.1.0; emacs 27.0.50 To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 16 12:24:00 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 1fU8NE-0004iv-Hs for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2018 12:24:00 +0200 Original-Received: from localhost ([::1]:50925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fU8PK-0006U0-3Z for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2018 06:26:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fU8OZ-0006Ts-Uc for emacs-devel@gnu.org; Sat, 16 Jun 2018 06:25:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fU8OV-0007Sf-GJ for emacs-devel@gnu.org; Sat, 16 Jun 2018 06:25:23 -0400 Original-Received: from exchange.tu-berlin.de ([130.149.7.70]:62718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fU8OV-0007Lj-3p for emacs-devel@gnu.org; Sat, 16 Jun 2018 06:25:19 -0400 Original-Received: from SPMA-03.tubit.win.tu-berlin.de (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0512C6C10B_B24E58BB for ; Sat, 16 Jun 2018 10:25:15 +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-03.tubit.win.tu-berlin.de (Sophos Email Appliance) with ESMTPS id 9D551692D8_B24E58AF for ; Sat, 16 Jun 2018 10:25:14 +0000 (GMT) Original-Received: from corax (178.199.231.181) by ex-mbx-10.tubit.win.tu-berlin.de (172.26.35.180) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 16 Jun 2018 12:25:14 +0200 X-ClientProxiedBy: EX-CAS-02.tubit.win.tu-berlin.de (172.26.35.182) To ex-mbx-10.tubit.win.tu-berlin.de (172.26.35.180) 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:226351 Archived-At: 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