From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: mithraeum Newsgroups: gmane.emacs.devel Subject: Re: Performance degradation from long lines Date: Fri, 26 Oct 2018 00:59:11 +0000 Message-ID: References: <83lg6mqdfh.fsf@gnu.org> <87r2gegd1r.fsf@web.de> Reply-To: mithraeum NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540515456 17352 195.159.176.226 (26 Oct 2018 00:57:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2018 00:57:36 +0000 (UTC) To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 26 02:57:32 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 1gFqRQ-0004R4-0q for ged-emacs-devel@m.gmane.org; Fri, 26 Oct 2018 02:57:32 +0200 Original-Received: from localhost ([::1]:57508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFqTW-0003Y8-Cl for ged-emacs-devel@m.gmane.org; Thu, 25 Oct 2018 20:59:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFqTK-0003WP-Id for emacs-devel@gnu.org; Thu, 25 Oct 2018 20:59:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFqTG-0000II-2V for emacs-devel@gnu.org; Thu, 25 Oct 2018 20:59:30 -0400 Original-Received: from mail-40135.protonmail.ch ([185.70.40.135]:20752) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gFqTF-0000Gx-OP for emacs-devel@gnu.org; Thu, 25 Oct 2018 20:59:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1540515556; bh=kVgaSn8CUQzrHjAuBrnVOM61CdQf/kxRjZAyjxM/foo=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=RHyXanp7f+q2gPV3cNlW6707CItlxn+lXLDJ3+YZ9Hy74Rz6ri1AutzHNTfVuUUjM e7ixFsjDMuRhKjqIb3GO0vmyV66jtu1W5ywdJNITW1X5s07RZXuSl4M11703sOvWme Xiq/OvqzxIl4VaqbpWSbpnisq5ZD7SGpbmcgqzug= In-Reply-To: <87r2gegd1r.fsf@web.de> Feedback-ID: xC_oeWz6JH8P2gZn7Lj2b-XCGuoCWrP5vJcnJIBITi8jaWWW0Er_cElwenRnHDRr1t8z5iqR6bQTnK1M9VLMtg==:Ext:ProtonMail X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.70.40.135 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:230674 Archived-At: On Thursday, October 25, 2018 10:18 AM, Michael Heerdegen wrote: > > BTW (I already discussed this with Eli some time ago), we already have a > solution in Emacs: longlines.el. It's obsoleted and a bit complicated, > but something like ... I just tested this solution on a 268K minified JSON file with 272307 characters on one line, and it worked amazingly well compared to the status quo of Emacs freezing when it encounters files with long lines even a tiny fraction of that length. It opened in a total of about 5 seconds, with it taking about 2 seconds before it prompted me as to whether to open it in longline mode or not, and about 3 more seconds to open the rest. At that point I had a fully font-locked version of the file opened in a JSON mode buffer. This made me very happy, and I think I wouldn't mind living with this solution as is until the root cause is solved, especially if I could get it to work on compilation-mode buffers as well, which I anticipate should be just a matter of adding it to a compilation-mode hook. I also tested this solution on a 663K minified JSON file with 671209 characters on one line, and this one took a little over a minute to open because it had a couple of long lines on the first screen, with each line measuring over 1000 characters. This is still better than what I'm used to, and once I was able to control-g to a useable buffer after just 30 seconds. There are two main issues with this solution: First, that it's still slow when there are some long lines in the resulting buffer. Second, that there is no indication in resulting buffer as to where the end of each real line is. I think Emacs has some ways to provide visual indicators of line endings, so I might try some of those out and see how they work with this mode. This still doesn't fix the root issue, but as a workaround it looks pretty good.