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

From: Gerd Möllmann <[email-masked]>
Date: Sat, 26 Apr 2025 18:34:11 +0200

Stefan Monnier <[email-masked]> writes:

>> * Results
>>
>>   | test          | non-gc (s) | gc (s) | gcs | total (s) | err |
>>   |---------------+------------+--------+-----+-----------+-----|
>>   | font-lock     |       0.52 |   0.32 |  23 |      0.83 |  0% |
>>   | smie          |       1.18 |   0.46 |  33 |      1.64 |  0% |
>>   | smie-nonascii |       2.10 |   0.49 |  35 |      2.59 |  0% |
>>   |---------------+------------+--------+-----+-----------+-----|
>>   | total         |       3.79 |   1.27 |  92 |      5.07 |  0% |
>>
>> Very nice! Can you tell the story a bit? For entertainment? :-).
>
> I didn't have time to get to the bottom of it, but here's what happened:
>
> - rebuilt with `--enable-profiling`.
> - ran the test then gprof.
> - told me >50% of the time was spent in `buf_charpos_to_bytepos`.
> - tweaked the source code to prevent inlining of the other functions
>   used in that code, to get more info from the profiler.
> - the new profile showed that a lot more time was spent in
>   `bytepos_backward_to_charpos` than in `bytepos_forward_to_charpos`.
> - I looked at the possible source of asymmetry and figured it might
>   be because of that corner case where we (needlessly) scan
>   backward from `next` when charpos is right at `prev`.
> - tried the patch which confirmed my suspicion.
> - called it a day.

Thanks!

And ouch, I hope that thing I tried there doesn't count as a premature
optimization (looks like one). That would betoo embarrassing :-).