From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: Performance degradation from long lines Date: Sat, 13 Jul 2019 21:33:19 +1200 Message-ID: <1a2d94be-a73a-7934-4ce8-5b3c4e819645@orcon.net.nz> References: <20190107065207.21793.53271@vcs0.savannah.gnu.org> <20190107065208.BA36C21736@vcs0.savannah.gnu.org> <16bb3884-c2de-b178-afe8-0b13a8b116a8@orcon.net.nz> <3f78c29c0c7c01e21180be5fe4f9e70a@webmail.orcon.net.nz> <11eaa87e-b4e4-2cf8-e9d1-658757b97ffe@orcon.net.nz> <83muhi1hoc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="163644"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 Cc: mithraeum@protonmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 13 11:33:40 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hmEPU-000gNi-EH for ged-emacs-devel@m.gmane.org; Sat, 13 Jul 2019 11:33:40 +0200 Original-Received: from localhost ([::1]:54296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmEPR-0003sr-QM for ged-emacs-devel@m.gmane.org; Sat, 13 Jul 2019 05:33:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53262) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmEPO-0003sh-AF for emacs-devel@gnu.org; Sat, 13 Jul 2019 05:33:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmEPM-0007tO-5N for emacs-devel@gnu.org; Sat, 13 Jul 2019 05:33:34 -0400 Original-Received: from smtp-2.orcon.net.nz ([60.234.4.43]:35425) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hmEPL-0007qb-QL; Sat, 13 Jul 2019 05:33:32 -0400 Original-Received: from [116.251.203.142] (port=51794 helo=[192.168.20.103]) by smtp-2.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1hmEPA-0000bj-0N; Sat, 13 Jul 2019 21:33:20 +1200 In-Reply-To: <83muhi1hoc.fsf@gnu.org> Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 60.234.4.43 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:238549 Archived-At: On 13/07/19 8:07 PM, Eli Zaretskii wrote: > One comment I have is that disabling bidi-display-reordering should > probably be removed from the defaults, because doing so puts the > display engine in a state that is not being tested, and can cause > inconsistencies and even bugs (because some portions of the code > were written under the assumption that this variable is never nil). > > OTOH, I'd suggest setting bidi-paragraph-direction to 'left-to-right > by default when so-long-mode is turned on. That sounds good to me. I wasn't aware that nil was an invalid value for bidi-display-reordering. I would suggest that its docstring be updated in this regard. Currently the doc is just "Non-nil means reorder bidirectional text for display in the visual order." which to me implies that value of nil is ok. > Also, I don't understand why the defaults disable > display-line-number-mode, it AFAIK does not slow down redisplay in > any significant ways. Do you have any evidence it should be > disabled in buffers with long lines? No, I'd simply included it along with the older line-numbering minor modes. I believe I can see a *very* slight difference, depending on the state of display-line-number-mode, when moving around the visual lines in a ~1MB line; however it's not significant, so I don't object to removing it from the list. I'm not sure that there's a benefit to the end-user in having line- numbering enabled in such a file, though (which was the other reason I went ahead and added all of those modes). Some of the default minor modes are in the list because I felt the features they provided would be redundant in a long-lines situation (or redundant with font-lock-mode disabled), rather than because I'd done benchmarking and established that they were notable CPU hogs. I'd concluded that any mode or feature which scans buffer contents in order to highlight things would be reasonable to disable by default, and my general approach has been to err on the side of being overly conservative in order to provide maximum benefit in the really extreme cases. I'm certain that the default settings can be improved though, so I'm very happy for them to be discussed, and I hope that people will do some experimentation in their own configs and recommend changes and additions to the defaults, so that 27.1 ships with better coverage in general -- the current defaults really only reflect things which I've used personally. > IME, truncate-lines sometimes makes display of long lines _faster_, > so I'm not sure we should disable that by default. This should stay. The combination of truncate-lines being disabled and line-move-visual being enabled is a tremendous benefit when the user tries to move vertically from an extremely long line to the next line. With truncated lines, Emacs will have to scan to the end of the line (one of my test files is a 19M JSON file in a single line*), whereas with the settings I've used the user can happily move up and down in the early parts of the file with no problems at all. (*) You can find that file in this Stack Overflow question: https://emacs.stackexchange.com/q/598 (see the 'wget' command). -Phil