bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: locked narrowing


From: Eli Zaretskii
Subject: bug#56682: locked narrowing
Date: Tue, 29 Nov 2022 16:25:01 +0200

> 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?

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

> 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.

> 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?

> > 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]