GNU bug report logs -
#77924
31.0.50; [Feature branch] Change marker implementation
Previous Next
Full log
View this message in rfc822 format
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> * master Results
>>>
>>> | test | non-gc (s) | gc (s) | gcs | total (s) | err |
>>> |---------------+------------+--------+-----+-----------+-----|
>>> | font-lock | 0.52 | 0.32 | 24 | 0.84 | 0% |
>>> | smie | 1.19 | 0.50 | 36 | 1.69 | 0% |
>>> | smie-nonascii | 2.13 | 0.53 | 39 | 2.66 | 0% |
>>> |---------------+------------+--------+-----+-----------+-----|
>>> | total | 3.83 | 1.35 | 99 | 5.19 | 0% |
>>>
>>> * text-index Results
>>>
>>> | test | non-gc (s) | gc (s) | gcs | total (s) | err |
>>> |---------------+------------+--------+-----+-----------+-----|
>>> | font-lock | 0.51 | 0.31 | 23 | 0.82 | 0% |
>>> | smie | 1.18 | 0.45 | 33 | 1.63 | 0% |
>>> | smie-nonascii | 5.49 | 0.48 | 35 | 5.98 | 0% |
>>> |---------------+------------+--------+-----+-----------+-----|
>>> | total | 7.19 | 1.24 | 92 | 8.43 | 0% |
>
> [ I'm surprised that I get 0 GCs in my tests whereas you get about 30.
> My crystal ball suggests it's because I ran them in batch whereas you
> ran them in a running Emacs, but even so: the difference is between
> a `gc-cons-percentage` of 1.0 vs 0.1 so it would explain a factor of
> 10 difference, but you have much more than 10 runs of GC. ]
Maybe it's redisplay. I'm not sure if --batch does a redisplay at all.
If it does that would be on the initial frame and probably a terminal
redisplay. But that's just a guess.
>>> That shows also the difference in smie-nonascii, i.e. in a C file
>>> containing multi-byte characters (one should suffice to make
>>> Z != Z_BYTE, and the index is used).
>>
>> I've been reading smie a bit, to get an impression what the smie
>> slowdown might mean in daily use. As far as I can see elb-smie is basically
>> 5 times
>>
>> (indent-region (point-min) (point-max)
>> -> indent-region-line-by-line for all lines
>> -> indent-region-according-to-mode
>> ...
>>
>> xmenu.c has ca. 2500 lines, so 12500 line-by-line indentations.
>> in 5.49s -> ca. 0.44ms per line. Or, taking 50ms as something a user might
>> perceive, 113 lines.
>
> As you know, that is not really the question. The question is rather:
> how/why does the new code slow down this benchmark by more than 2x even
> though this benchmark is not expected to spend its time in marker
> manipulation and charpos<->bytepos conversion.
>
> I hope something like `gprof` might give useful hints.
See my other reply talking about building the index. I think the fast
one doesn't build_index and the slower one does. Also just gut feeling.
Profiling on macOS is a big PITA, BTW :-)
This bug report was last modified 105 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.