bug#56682: locked narrowing

[Dmitry Gutov]

On 29/11/2022 16:25, Eli Zaretskii wrote:
> > Date: Tue, 29 Nov 2022 15:21:12 +0200
> > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > > 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.

dictionary-pp.json.xz
Description: application/xz