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.bugs Subject: bug#32729: Xemacs 23 times as fast as GNU Emacs Date: Sun, 13 Oct 2019 23:49:41 +1300 Message-ID: <5b3b2f98-20e6-596d-2c02-0821def8ae40@orcon.net.nz> References: <871rviobu2.fsf@gnus.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="57432"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: Kevin Layer , "Benninghofen, Benjamin Dr." , 32729@debbugs.gnu.org, 32728@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 13 12:53:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1iJbUv-000EkV-1E for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Oct 2019 12:53:13 +0200 Original-Received: from localhost ([::1]:38690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJbUt-0000g2-TZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Oct 2019 06:53:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60750) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJbRs-0000C0-3H for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2019 06:50:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJbRq-0005j6-SY for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2019 06:50:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54662) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iJbRq-0005j2-QA for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2019 06:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iJbRq-0007te-MF for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2019 06:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Oct 2019 10:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32729 X-GNU-PR-Package: emacs Original-Received: via spool by 32729-submit@debbugs.gnu.org id=B32729.157096378930322 (code B ref 32729); Sun, 13 Oct 2019 10:50:02 +0000 Original-Received: (at 32729) by debbugs.gnu.org; 13 Oct 2019 10:49:49 +0000 Original-Received: from localhost ([127.0.0.1]:35249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iJbRc-0007su-JX for submit@debbugs.gnu.org; Sun, 13 Oct 2019 06:49:48 -0400 Original-Received: from smtp-2.orcon.net.nz ([60.234.4.43]:33701) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iJbRZ-0007sg-Ag; Sun, 13 Oct 2019 06:49:46 -0400 Original-Received: from [116.251.203.173] (port=2746 helo=[192.168.20.103]) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1iJbRV-0003Bn-5Z; Sun, 13 Oct 2019 23:49:41 +1300 In-Reply-To: <871rviobu2.fsf@gnus.org> Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:169113 Archived-At: On 12/10/19 4:57 PM, Lars Ingebrigtsen wrote: > (Note: Don't visit the " *zeroes*" buffer after this, because that > will hang Emacs totally. I guess the long-line display problem > hasn't been fixed after all?) I imagine you're thinking of so-long.el here, in which case there may be a misconception. so-long helps tremendously in certain situations, but it doesn't (and cannot) eliminate all sources of potential slowness in the face of extremely long lines -- ultimately the C code still needs time to process the lines being displayed, and so-long.el can't make that code work any faster. The biggest problem in this case (by far) is that point has been left at the end of the line following the insertion, and in order for the redisplay to *display* the end of the line, it's having to process a gigabyte of data. My largest test case for so-long.el was a couple of orders of magnitude smaller than this, and Emacs wasn't remotely happy showing the end of that line, let alone this one. (What so-long is really good at is preventing situations whereby merely visiting a file -- with point still at the beginning of the buffer -- caused Emacs to hang badly; which can easily happen when various modes and options are active. It can work wonders in those cases. If you try to display the end of a really gargantuan line of data like this, though, you're simply at the mercy of other factors.) If you added a (goto-char (point-min)) before switching to the *zeroes* buffer then, given that there's not much else happening in that buffer which would create issues, Emacs shouldn't hang when you switch to it. The further you move into that line, though, the worse the performance is going to get (so the key take-away here would be to avoid doing that when dealing with this kind of data, if at all possible). Also note that `so-long' doesn't actually trigger automatically if you simply create a buffer and throw a ton of data into it. The automatic behaviour is tied to `set-auto-mode' and intended to deal with users visiting files. Auto-detecting the sudden insertion of large lines into an existing buffer is a different kettle of fish, and the current library does not attempt to cater for it. So if you wanted to trigger it in this example you would need to call it explicitly. -Phil