Sławomir Grochowski <[email protected]> writes:
[You forgot to CC the list; fixed here.]
> Thanks for the feedback, Rudy. I agree that the function lost some
> readability and maintainability. I was actually torn between the two
> versions and initially prioritized speed, but looking at the benchmarks,
> we're talking about microseconds that a user will never notice. This
> function won't be a bottleneck, so I'm glad you pointed that out.
With 2000 rows and 10 columns, we have +25 milliseconds, which is an
observable UI lag. A couple of lags like that can make a program feel
all syrupy. Thus, I do agree regarding your motivation, and I applaud
your effort to make Org faster! We all want it. Really, all I wanted
to point out is that, for less smart folks like me, the implementation
you propose is a bit too "rocket science", requiring in-depth study as
opposed to a quick scan, compared to the original.
> I would like to revert to the cl-loop version, as it seems the
> most elegant and readable to me:
>
> (dolist (entry cache)
> (cl-loop for i from 0
> for triplet in (cdr entry)
> do (setf (nth i widths)
> (max (nth i widths) (string-width (nth 2 triplet))))))
>
> What are your thoughts on this?
It is objectively simpler than the proposed variant. Me, I would also
indent `string-width` below `nth` for maximum readability, and perhaps
even spell our `index`, making it as 101 as possible:
(dolist (entry cache)
(cl-loop for index from 0
for triplet in (cdr entry)
do (setf (nth index widths)
(max (nth index widths)
(string-width (nth 2 triplet))))))
Rudy
--
"It is better to have 100 functions operate on one data structure than
10 functions on 10 data structures."
--- Alan Perlis
Rudolf Adamkovič <[email protected]> [he/him]
http://adamkovic.org
