GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On 29/11/2022 16:25, Eli Zaretskii wrote:
>> Date: Tue, 29 Nov 2022 15:21:12 +0200
>> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> 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 (application/x-xz, attachment)]
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.