From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Performance degradation from long lines Date: Thu, 25 Oct 2018 18:00:18 +0300 Message-ID: <83lg6mqdfh.fsf@gnu.org> References: NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1540483494 30473 195.159.176.226 (25 Oct 2018 16:04:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 25 Oct 2018 16:04:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: mithraeum Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 25 18:04:50 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 1gFi7p-0007h1-3n for ged-emacs-devel@m.gmane.org; Thu, 25 Oct 2018 18:04:45 +0200 Original-Received: from localhost ([::1]:55416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFi9v-0003UH-HG for ged-emacs-devel@m.gmane.org; Thu, 25 Oct 2018 12:06:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFh80-0007LS-8A for emacs-devel@gnu.org; Thu, 25 Oct 2018 11:00:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFh7r-0003W7-II for emacs-devel@gnu.org; Thu, 25 Oct 2018 11:00:47 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFh7m-0003TY-6t; Thu, 25 Oct 2018 11:00:41 -0400 Original-Received: from [176.228.60.248] (port=2837 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gFh7W-0005YN-9I; Thu, 25 Oct 2018 11:00:28 -0400 In-reply-to: (message from mithraeum on Wed, 24 Oct 2018 23:59:02 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:230661 Archived-At: > Date: Wed, 24 Oct 2018 23:59:02 +0000 > From: mithraeum > > In the case of gui Emacs, the reduction of display capability is real, > but it seems prefereable to freezing Emacs or slowing it down to a crawl. It is only preferable if the resulting display will be acceptable by enough users to justify the costs of developing and maintaining the separate "simplified" display code. > It also seems better than, or at least a viable alternative to, opening > files with M-x find-file-literally, which loses font-lock and leaves > the buffer stuck in Fundamental mode. Again, only if the result of the "simplified" display will be more acceptable than Fundamental mode by enough users. The significant advantage of find-file-literally is that it already exists, and so incurs exactly zero costs. > In the r/emacs thread I was encouraged to post to emacs-dev to get > the input of more developers, so here I am. The main motivation for my request to start a discussion here was to find out whether such a "simplified" display will be acceptable on GUI frames by enough users. In r/emacs thread, I described some features that will be lost (I can repeat here if people prefer that); please consult that if you want to make up your mind and provide opinions. IMO, the costs for developing and maintaining such a "simplified" display code will only be justified if enough people will consider the resulting display both acceptable and significantly preferable to what find-file-literally already provides. > First is that Emacs could have a user-configurable timeout after which > it could warn the user that it's taking an unexpectedly long time to > open a file (or find the end of a line) and ask whether to abort, > continue trying, or drop down to a mode with reduced display > capabilities (which could be either the equivalent of > find-file-literally or the above simplified display techniques, if > they're implemented). First, it isn't visiting the file (i.e. reading it into a buffer) that takes time; in fact, the time to visit is almost entirely unaffected by line length. What takes time is the display of the initial windowful of the file's text (and following redisplay as result of editing). So I guess the proposal is to have a time-out on that initial display and on redisplay cycles. Second, I'm not sure we need to measure the time; line length is a reliable enough indication of expected display slowdown, so we could simply look at the typical line lengths instead, which is much simpler to implement. And third, it seems like so-long mode already implements this idea, so perhaps we should simply add it to the core and integrate it by default. > The second idea is to use to ignore anything that would slow Emacs > down while doing a simple count of the line length, and if the line > length so far is over a certain threshold to ask the same questions as > above about aborting, continuing, or dropping down to a fail-safe > mode. See above. Please note that these ideas are a kind of "band-aid": they don't solve the root causes for the slow display, they just disable some features which make that slow display even slower, and by that make the critical line length larger. But you can still create a file with lines so long that even in Fundamental mode it will be painfully slow to move through and edit. > The third is to use some of Emacs' new async abilities to try to open > the file. It might still take forever to open, but at least it shouldn't > freeze all of Emacs in the meantime. There are no such abilities; the concurrency features in Emacs 26 don't allow running the display code in a separate thread. Emacs Lisp threads are mostly cooperative, and only one thread is allowed to run at any given time. And the current design of Emacs is such that redisplay must run from a Lisp thread.