From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#56682: locked narrowing Date: Tue, 29 Nov 2022 15:21:12 +0200 Message-ID: References: <831qtgff78.fsf@gnu.org> <83zgg4dw4y.fsf@gnu.org> <83r11gdrr4.fsf@gnu.org> <83edxfds7s.fsf@gnu.org> <83r11fc80o.fsf@gnu.org> <83o7wjc6o2.fsf@gnu.org> <83lernc5gu.fsf@gnu.org> <83k076dd7d.fsf@gnu.org> <83czcyd8jf.fsf@gnu.org> <83a682d66r.fsf@gnu.org> <837d36ceno.fsf@gnu.org> <37dd2827f54f8bbda5e3@heytings.org> <735c1d5b-0d64-a8e1-3aaa-91fc0248abd3@yandex.ru> <83h6yilyfo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17344"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 29 14:22:22 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p00Z4-0004Fz-4w for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Nov 2022 14:22:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p00Ym-0000F0-Q1; Tue, 29 Nov 2022 08:22:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p00Yl-0000Ee-38 for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 08:22:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p00Yk-0003HM-Cm for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 08:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p00Yj-0002P5-W8 for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 08:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2022 13:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.16697280919232 (code B ref 56682); Tue, 29 Nov 2022 13:22:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 29 Nov 2022 13:21:31 +0000 Original-Received: from localhost ([127.0.0.1]:54482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p00YB-0002Oq-TG for submit@debbugs.gnu.org; Tue, 29 Nov 2022 08:21:30 -0500 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:42765) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p00Y6-0002Oi-CH for 56682@debbugs.gnu.org; Tue, 29 Nov 2022 08:21:26 -0500 Original-Received: by mail-wr1-f48.google.com with SMTP id w15so8845938wrl.9 for <56682@debbugs.gnu.org>; Tue, 29 Nov 2022 05:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=ir1x0Cp0SLphZT3Ly79dzyLNG8ZlOZVaVzzVh8BhRaU=; b=R3o02XT4ye5EENvJwYl+R92+o2+yn+D8JS7w00SFMV7ZFzAtzEP5JYmBtNJzJdG3BZ QPK2FCSex3LwzE3ftq7eNwzHYzfbOu2gOra3FkjisqrS3YjPtC0H+H1YdZTfDt1HAGcS fLy9dpq6LoWGuCMGCjdCP6bDKBdTVxqMdJ2qTY1Ul+/6Y1VMggXjcZXT23n5ZIJgUKQ7 jpbVN7bYxbZxvp/yQy1p9A5p5v7clhVylywN2wqJ6xxnG5nOs9h970OafHLwdEfw/q8z SMh1cNAZUpkJKF+PzFxcHv/e61JqLPJ46LCHBs6YadkiDqi7BdCDjTKvdh694NUY8VwO f8Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ir1x0Cp0SLphZT3Ly79dzyLNG8ZlOZVaVzzVh8BhRaU=; b=Dik8fFLjsHlCu7z+kYY2y/tOgwWofNfqheq+npZGvwPSUCZeAYcqIpJg0IZc76CKP8 tMJ8QAOy+TomwVvXd7MynoEeaXtbxM/TlGG9DBFpLmu957HazHceKdUb5QO1fAxOvFo+ 3uZseDZ7P5ZrjpA/xfl2xlW1ZmY5TrtfUa81tOAdEZq3JlJzX2UwNd0XjpCwekS22zwn ls+dVvczDPbdqlavShzIWNxUcXTiben2NJumEJHEWKocNwsbLERtEP9XAXs3vLhNkJBN LPoxY18dhGfTYwvYZ4fod3qqF0MYGzA2d6wvGGNuCn1PVTzOaUTMmI6HJ42FcpAUKQQW p/rA== X-Gm-Message-State: ANoB5pmXZRO5oZBTlu2gft/BU/5bgGjZaYLQHZyssU34aBeNgB3q7aX0 AXhhIx5+qFawZYtI4TByAt0= X-Google-Smtp-Source: AA0mqf6PHgpD4LIAT2giLxQ80QuujZ8eIXJ/JPrwAadGpRvCQcoPE97Vw/bVOwo3TouhRY4lyRpvDA== X-Received: by 2002:adf:e18c:0:b0:242:989:d9cb with SMTP id az12-20020adfe18c000000b002420989d9cbmr12113845wrb.716.1669728075160; Tue, 29 Nov 2022 05:21:15 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h20-20020a05600c351400b003c6cd82596esm2451037wmq.43.2022.11.29.05.21.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 05:21:14 -0800 (PST) Content-Language: en-US In-Reply-To: <83h6yilyfo.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249395 Archived-At: On 29/11/2022 14:47, Eli Zaretskii wrote: >> Date: Tue, 29 Nov 2022 05:20:30 +0200 >> Cc: Eli Zaretskii , Stefan Monnier , >> 56682@debbugs.gnu.org >> From: Dmitry Gutov >> >> Another thing that bothered me when testing: going from eob to bob in >> dictionary.json took ~4 seconds every time, independent of buffer being >> edited or not. And that delay didn't show up anywhere in the profiler. >> (setq bidi-inhibit-bpa nil) didn't help at all, but (setq >> bidi-display-reordering nil) eliminated that delay. So I'm still kind of >> puzzled why we bother to restrict font-lock, but didn't do that with >> this significantly more costly computation. > > Why do you think we didn't restrict them? Limitations on costly > bidi-related stuff is in Emacs since the very beginning, in v24, AFAIR. And > no code in bidi.c or xdisp.c ever goes outside the current narrowing. Just because it was really slow. Apologies, I seem to be unable to reproduce this effect now. I'll get back to this if I see it again. >> Even with with common setup (and emacs -Q): >> >> 1. (setq long-line-locked-narrowing-region-size 50000) >> 2. (setq bidi-display-reordering nil) >> 3. Toggle show-paren-mode off, just in case. >> 4. electric-pair-mode off, same. >> >> typing in the latter file exhibits random pauses in redisplay up to 0.5s >> (and sometimes 1s+). I haven't managed to catch the exact source of >> those pauses (and they're longer with my personal config), but even >> regular editing is slower: evaluating >> >> (benchmark 1 '(progn (insert " ") (redisplay t))) >> >> in dictionary.json reports something like 0.038906s, but in >> dictionary-pp.json it prints ~0.136387s. > > It is wrong to discuss here issues that are evidently unrelated to long > lines and the measures to make Emacs more efficient with long lines. Please > file a separate bug report about the delays you see, and please post there > the file dictionary-pp.json you used in these tests. Bonus points for > including in the report buffer positions where "typing exhibits random > pauses in redisplay", to make search for those more efficient. My theory was that it's likely related, since there haven't been any other major changes to the display engine later. Of course I could be mistaken. If you don't see the problem right away, sure I can file this separately. dictionary-pp.json is produced from dictionary.json using 'M-x json-pretty-print-buffer'. It's 27 MB long, do you want me to upload it to some file sharing platform? Positions: any near bob. The profiler output looks like this: 526 87% - command-execute 516 85% - call-interactively 378 62% - funcall-interactively 370 61% - eval-expression 370 61% - eval 370 61% - benchmark 370 61% - benchmark-call 194 32% - # 194 32% - progn 194 32% redisplay 160 26% - # 160 26% - progn 160 26% redisplay 16 2% - # 16 2% - progn 16 2% redisplay > Last, but not least: the "optimizations" (I prefer to call them "shortcuts") > which we installed for making Emacs more responsive with long lines are just > that: shortcuts. They deliberately ignore certain possible complications in > buffer text and properties/overlays, and bypass the potentially costly code > which handles them, in order to make the display code significantly faster, > at a price of being less accurate and correct. So I'm not surprised that > you sometimes see faster redisplay with long lines: it could well be due to > these simplifications -- and the price is that in some situations the > display will be incorrect. So it could turn out that there's nothing wrong > with the "unoptimized" redisplay: it simply sometimes takes time to do all > that it has to do to produce correct display on the screen. The resulting > loss of accuracy and/or correctness is IMO justified when lines are so long > as to make Emacs unusable without these shortcuts, but not when Emacs can > cope with the complete and accurate display perfectly well, albeit somewhat > slower. So you might be basically comparing apples with oranges here. > > But that is theory: we need specific recipes to investigate the causes for > the delay. > >> Commit 89a10ffc (before the last merge) behaves the same, but going >> further back, this commit from July behaves differently: b283e36cf19. >> >> Emacs built from that version reports ~0.033022s in dictionary-pp.json >> and 0.114781s at bob in dictionary.json (scrolling to the end >> predictably freezes that Emacs build). > > I don't understand what exactly you timed here (since it cannot be scrolling > to eob). Is it the "insert one SPC" or is it something else? "insert one SPC and redisplay". The 'insert' call by itself is very fast. > In any case, 0.114781s just 19% (and 22 msec) slower than 0.136387s, so is > this something serious to talk about? There could be any number of reasons > for this, including some changes to the JSON mode, perhaps? It's 0.114 vs 0.033 (in dictionary-pp.json, file without long lines).