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:
>> * 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 :-).
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.