Subject: Re: bug#77924: 31.0.50; [Feature branch] Change marker implementation

From: Stefan Monnier <[email-masked]>
Date: Fri, 25 Apr 2025 12:34:04 -0400

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