GNU bug report logs -
#77924
31.0.50; [Feature branch] Change marker implementation
Previous Next
Full log
Message #239 received at 77924 <at> debbugs.gnu.org (full text, mbox):
>> * 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. ]
>> 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.
Stefan
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.