Subject: Re: bug#56682: locked narrowing

From: Dmitry Gutov <[email-masked]>
Date: Tue, 29 Nov 2022 17:26:46 +0200

On 29/11/2022 16:25, Eli Zaretskii wrote:
>> Date: Tue, 29 Nov 2022 15:21:12 +0200
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>>> 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.
> 
> What is not reproducible? the 0.5sec delays or something else?

This part:

"going from eob to bob in dictionary.json took ~4 seconds every time"

> Is it still worth our while to look at the dictionary-pp.json file and the
> slow redisplay with it?

Yes.

>> 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?
> 
> If you compress it with xz, doesn't become small enough to post here?
> 
> If not, please upload somewhere and tell where.

It's 3 MB compressed. Let's see if it's small enough as an attachment.

>> 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%        - #<lambda 0x91bc787b0d851>
>>            194  32%         - progn
>>            194  32%            redisplay
>>            160  26%        - #<lambda 0x91bc787b0d851>
>>            160  26%         - progn
>>            160  26%            redisplay
>>             16   2%        - #<lambda 0x91bc787b0d851>
>>             16   2%         - progn
>>             16   2%            redisplay
> 
> This seems to say redisplay takes about 1/3rd of the time?

I wouldn't pay too much attention to the exact percentages. E.g. the 23% 
percent drop between call-interactively and funcall-interactively 
doesn't make much sense either. But here the 3 lambda-s are on the same 
level, meaning the combined time for redisplays should be summed: 32% + 
26% + 2%.

Anyway what's significant is 'redisplay' call does take up a fair 
fraction of time, and that it doesn't expand into anything (i.e. there 
are no Lisp calls inside that are responsible for the delay).

>>> 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).
> 
> I thought you were saying that Emacs at commit 89a10ffc and at current HEAD
> took 0.136387 sec, which is slower than 0.114 sec at commit b283e36cf19
> (from July)?  The 0.033 figure is with long-line optimizations, no?  So it's
> a very different buffer text and different code paths.

I said:

 >>>> in dictionary-pp.json it prints ~0.136387s ... [current emacs-29]

 >>>> this commit from July behaves differently: b283e36cf19.

 >>>> Emacs built from that version reports ~0.033022s in dictionary-pp.json

The figure of 0.114 sec is for dictionary.json (in July Emacs). Which is 
the same file but with all contents on one line.