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 >> >>> 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% - # >> 194 32% - progn >> 194 32% redisplay >> 160 26% - # >> 160 26% - progn >> 160 26% redisplay >> 16 2% - # >> 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.