Very interesting, there's a lot of elisp for me to learn about in the patch
(I didn't know about pcase, which looks *powerful*).

Cheers,

Derek

On Sun, May 10, 2026 at 5:10 AM Sławomir Grochowski <
[email protected]> wrote:

> Hi everyone,
>
> I spent way too much time on something no user will ever notice.
>
> While poking around `org-columns--set-widths' I realized the old code was
> O(n×m) for no good reason — it
> rescanned the entire cache once per column. So naturally I had to fix it,
> even though the absolute
> numbers are microscopic.
>
>
> What changed
> ------------
> The old algorithm computed column widths "vertically" — for each column it
> scanned the entire cache
> with `assoc', giving O(n×m). The new code reads "horizontally" — it walks
> each cache row once, advancing
> list pointers in lockstep with the column definitions. Result: O(m).
>
>
> Why not `cl-loop`
> ----------------
> I tried an elegant cl-loop version first, but Emacs Lisp lists are
> singly-linked, so nth inside the
> loop reintroduces O(k) lookups. A plain while with manual setq/setcar
> pointer-walking turned out
> fastest.
>
>
> Benchmarks
> ----------
> Benchmark (10 runs each, widths auto-computed from cache)
>
>     10 columns (practical case — fits on screen without scrolling):
>        Rows   Cols   Old O(n×m)   cl-loop     New while    Speedup
>        ───────────────────────────────────────────────────────────
>          10     10    0.00019 s   0.00016 s   0.00022 s    0.9×
>         100     10    0.00174 s   0.00116 s   0.00107 s    1.6×
>         500     10    0.00939 s   0.00694 s   0.00501 s    1.9×
>        1000     10    0.01863 s   0.01347 s   0.01256 s    1.5×
>        2000     10    0.05089 s   0.02652 s   0.02515 s    2.0×
>
>     20 columns (for completeness):
>         500     20    0.03454 s   0.01470 s   0.01096 s    3.2×
>        2000     20    0.09045 s   0.05868 s   0.05020 s    1.8×
>
>
> Nobody is going to perceive this.  But here's the thing — I had so much
> fun.  Chasing microseconds, trying cl-loop, watching it lose, reverting
> to a raw pointer walk, seeing the while consistently beat the prettier
> version by 20%... this is the kind of deeply pointless optimization that
> makes hacking on Emacs so satisfying.
>
> The patch is on main and I'm also attaching it here.
>
> Feedback welcome — especially if anyone sees a way to squeeze more out of
> it!
>
> Best,
> --
> Slawomir Grochowski
>
>

-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| GPG Key available at https://keybase.io/dchenbecker and       |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---------------------------------------------------------------+

Reply via email to