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 01:46:29 +0000 Message-ID: References: <665d5f3d84c071632f87f66ffedb6aed@webmail.orcon.net.nz> 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 1540518292 18510 195.159.176.226 (26 Oct 2018 01:44:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2018 01:44:52 +0000 (UTC) To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 26 03:44:48 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 1gFrBA-0004jW-3s for ged-emacs-devel@m.gmane.org; Fri, 26 Oct 2018 03:44:48 +0200 Original-Received: from localhost ([::1]:57630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFrDG-0004eX-E6 for ged-emacs-devel@m.gmane.org; Thu, 25 Oct 2018 21:46:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58653) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFrD7-0004eQ-NJ for emacs-devel@gnu.org; Thu, 25 Oct 2018 21:46:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFrD2-000055-Sb for emacs-devel@gnu.org; Thu, 25 Oct 2018 21:46:49 -0400 Original-Received: from mail-40135.protonmail.ch ([185.70.40.135]:45678) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gFrD2-0008Vd-DJ for emacs-devel@gnu.org; Thu, 25 Oct 2018 21:46:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1540518395; bh=FwGpdYiZ/mWHr/z8niQotSkyTziS4HvhsgsfQJJ81KI=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=WKduw5ZEUn0hZw652oV2nHSwkgCa9TjPL3h3BqO/Yhbp6JtC+2Zpg1+Mpo/hZLHVw MyecfmCp+j/nimxBS89mOloTgV2QJ3zBbEVXycmbf/RrGNz3Zc+WqwdO52aK0PdfH0 6pePaK1Vt+pvNBKEJD11oAWjplDrXOxJkvzz2eEE= In-Reply-To: <665d5f3d84c071632f87f66ffedb6aed@webmail.orcon.net.nz> 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:230675 Archived-At: > On 2018-10-25 12:59, mithraeum wrote: > > Broadly speaking, this is what so-long.el is about. It does not help > with the redisplay code itself, but it disables elisp-visible options > which it considers may affect performance under long-line conditions. > > https://savannah.nongnu.org/projects/so-long I tried out so-long's wip branch on the same files I tested longlines.el on, and here are the results: First I tested it on a 268K minified JSON file with 272307 characters on one line, and it opened in about 3 seconds. All the text remained on one line, as in the original, but there was no font-lock, and I was in so-long mode (which, from what I understand, is much like Fundamental mode), not json-mode. Then I tried opening the 663K minified JSON file with 671209 characters on one line. It took a little over 4 minutes to open. I then tried it again and gave up after about 7 minutes, and when hitting control-g and escape a bunch of times did nothing, I did a "kill -s SIGUSR2" on the emacs daemon process and was dropped in to the debugger, from which I quit and was able to continue using Emacs as before. I have no idea how typical these file sizes and line lengths are compared to what other Emacs users encounter on a regular basis. I have a feeling that they're larger than usual, but really I don't know. In the cases where the user encounters lines as long as that second test file, it doesn't really look like a workable solution. Also, I should mention that this second file had a ton of non-ascii, unicode characters in it. I'm not sure if that made a difference, but it might. The nice/not-nice aspect of so-long-mode is that, when it works, the user is still dealing with the original line lengths in the file. This is advantageous when one wants to see the file as it was. It's not so great, though, as a lot of the typical editing commands really aren't geared towards working with lines that long, so it's much more convenient to work with lines the length provided by longlines.el I think in a realistic scenario, when I run across such minified files, I'd probably want to run them through a beautifier, then switch them to a mode that supports font-lock (like the native json-mode), and after I'm done editing re-minify them if need be (maybe outside of Emacs, or in Emacs but after re-enabling so-long-mode or longlines.el). For my own use cases, however, I think most of the time I probably wouldn't be editing these super long files in the first place, but just want to view their beautified versions with font-lock on. In any event, it's great to have both of these options in Emacs already. Their presence and usefulness should be more widely known. If longlines.el needs some updating to make it non-obsolete or to deal with its own issues, that could be helpful too.