Gerd Möllmann writes: > Stefan Monnier 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 :-). To fix this, I would propose