From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#38407: 27.0.50; infinite loop with display of large file without newlines Date: Thu, 05 Dec 2019 08:27:00 +0100 Message-ID: References: <39c498717f8958e7fdc408d4da51d378@webmail.orcon.net.nz> <24031.28277.201123.531348@cochabamba.vanoostrum.org> <83r21sowx1.fsf@gnu.org> <24032.4698.256238.87458@cochabamba.vanoostrum.org> <83k17jq1ch.fsf@gnu.org> <24032.17845.921546.629745@cochabamba.vanoostrum.org> <83fti7p349.fsf@gnu.org> <4B1ABCA7-A69C-4251-8EBD-A11654A92642@vanoostrum.org> <83v9r2o4z9.fsf@gnu.org> <24035.27244.755074.180653@cochabamba.vanoostrum.org> <83lfrwlz2w.fsf@gnu.org> <83o8wpjsx5.fsf@gnu.org> <83zhg8hz6j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="18960"; mail-complaints-to="usenet@blaine.gmane.org" Cc: psainty@orcon.net.nz, pieter@vanoostrum.org, 38407@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 05 08:28:34 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 1iclYw-0004oL-Gi for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 08:28:34 +0100 Original-Received: from localhost ([::1]:50958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iclYv-0007Tz-2l for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 02:28:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34632) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iclYV-0007Tg-T3 for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 02:28:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iclYR-0000Xx-9R for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 02:28:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36963) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iclYQ-0000WZ-Nb for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 02:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iclYQ-0000d4-JW for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 02:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Dec 2019 07:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38407 X-GNU-PR-Package: emacs Original-Received: via spool by 38407-submit@debbugs.gnu.org id=B38407.15755308302300 (code B ref 38407); Thu, 05 Dec 2019 07:28:02 +0000 Original-Received: (at 38407) by debbugs.gnu.org; 5 Dec 2019 07:27:10 +0000 Original-Received: from localhost ([127.0.0.1]:42936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iclXa-0000b1-FL for submit@debbugs.gnu.org; Thu, 05 Dec 2019 02:27:10 -0500 Original-Received: from mail-wm1-f54.google.com ([209.85.128.54]:52787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iclXZ-0000al-1t for 38407@debbugs.gnu.org; Thu, 05 Dec 2019 02:27:09 -0500 Original-Received: by mail-wm1-f54.google.com with SMTP id p9so2433765wmc.2 for <38407@debbugs.gnu.org>; Wed, 04 Dec 2019 23:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=4eaOZ73yPeyzr4efO0iRzdNj09b2wZfhQRj1rteewUI=; b=I4oR3ei/flY/mE8KAEVINhtBujjLPKRHqZfZxzB+WekBsHS0/2c7utpOHzKOJbAco/ Tp7NLP1bDMIaFW5eINYOCV8ubi+wRQ7iIDUP3kfrjIZzbyyipE0nI7clMpgQWw05nDkO +m6hS/+dXgBm6Ys/Bm6P6OmsYLKFansGXNyvTTKosEm+RzBiI4RgRfrAvF9wO5I2ZpBX YgNSeG/WImr4vHT1jx12INFOWBVz3H6muDZRRQyUBQMRQwfz1w1cr8hkuGBk87bNEvIK j8EpxRKo+eUN93UPEHAmJi1AWVxob03Cf3oGySQrVIt52AUPrUj19fjRvjre0g0NRKTi Fnrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=4eaOZ73yPeyzr4efO0iRzdNj09b2wZfhQRj1rteewUI=; b=CNhIDYgIwY/jzdi9Pz6HiTmTWvJs4qCz6jGTEnwUCy8ouk5JyhEuuloZWc9jdcvKUb MdM1Yh8YpXRdYL//p52cx74tCg0+ZPknuNiG7zwTIRiABjs6T+5AcilC4QZqqXeHl3xl HeXXwUEQZ7UYEivXiZCbXT1c5xeifsPrCSpDReXaNwqmVEtaa3nfK5kJYpVe10p2cCh5 mDeLBaElO9G6k2jISksnjEe1PE0uNRCFzQIsSm9zCogKqpmbYTkoNOu9Qk4I0eu2V2M6 +9gnjLGELpJIVCiC8ZBswIPWCsMEoqYC5uhDsuw5p8a7FkkN50WIr74AldAhKjcKz9OA 2OkA== X-Gm-Message-State: APjAAAWwGN9yEdk6jh59R5MT7BYszM2Hz4qryeVpcCSFyXe4MnNvQoVE 3B0zDWiCMiswx73RCN/uKCk+e3zd X-Google-Smtp-Source: APXvYqxNQWBe3uyHAJLb4vI4z6l9KhjvTlNK4j93HHFvRW/JTNbFTrjsw17RkJ3skZPXsVANwXZvUQ== X-Received: by 2002:a1c:8156:: with SMTP id c83mr3424537wmd.59.1575530822591; Wed, 04 Dec 2019 23:27:02 -0800 (PST) Original-Received: from rpluim-mac ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id u22sm12276613wru.30.2019.12.04.23.27.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Dec 2019 23:27:01 -0800 (PST) In-Reply-To: <83zhg8hz6j.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 04 Dec 2019 17:45:40 +0200") 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:172873 Archived-At: >>>>> On Wed, 04 Dec 2019 17:45:40 +0200, Eli Zaretskii said: >> Thread 1 "emacs" hit Breakpoint 3, bidi_shelve_cache () at bidi.c:981 >> 981 alloc =3D (bidi_shelve_header_size >> $25 =3D 30860 >> $26 =3D 71842080 >>=20 >> which means Emacs is copying 70MB of data every time bidi_shelve_cac= he >> is called, and it=CA=BCs called *a lot* in this scenario. Could we n= ot do >> this shelving by pointer-swapping or similar rather than copying? Eli> Not sure I understand what kind of pointer-swapping you had in min= d. Eli> We don't swap between 2 buffers here, we save away a snapshot of t= he Eli> iterator state each time we see a character where a line break can= be Eli> made, so that we could restore that state when we exhaust the wind= ow's Eli> width. We must restore the iterator state to continue to the next Eli> visual line, and the bidi cache is an integral part of that state. Yes, I hadn't realized you needed to keep a copy of the data. Eli> We could perhaps lower the cache size limit (see Eli> BIDI_CACHE_MAX_ELTS_PER_SLOT in bidi.c), which would then Eli> proportionally decrease the time for making a copy of the Eli> cache. I tried various values of that down to 5000, it improved matters by a factor of 8 or so, but the resulting Emacs was still pretty laggy (with visual-line-mode enabled). Eli> Or Eli> we could make some non-trivial changes in the logic of Eli> move_it_in_display_line_to (and similar changes in display_line) to Eli> detect when the cache becomes too large, and use a backup algorithm Eli> that doesn't copy it. But I question the utility of such changes: Eli> they will never get us a speedup like bidi-inhibit-bpa does, and f= or Eli> the relatively rare use case like this one (extremely long lines i= n a Eli> JSON file, with some bracketed parts containing R2L text, and the = user Eli> activating visual-line-mode on top of that) inhibiting the BPA, Eli> whether via so-long or by the user or some other Lisp, sounds like= an Eli> okay solution to me. If the JSON file has long lines, but no R2L Eli> text, we already have an optimization in bidi.c to avoid having a Eli> large cache; and if visual-line-mode is off, the cache doesn't nee= d to Eli> be copied so frequently. So only the combination of the two causes Eli> this tremendous slowdown, and bidi-inhibit-bpa solves it better th= an Eli> any alternative. WDYT? That sounds reasonable. I see global-so-long-mode is off by default, do we want to enable it by default? It seems a dis-service to users to make them have to find out about it by themselves. Robert