> From: Kristoffer Balintona <krisbalintona@gmail.com>
> Date: Wed, 9 Apr 2025 17:13:10 -0700
>
> Attached is a patch to vtable.el that improves the performance of
> vtable-limit-string. This is because of the expensive calls to
> string-pixel-width.
>
> The current implementation of the function is O(n), whereas the version
> in the attached patch uses a binary search, which has an improved time
> complexity of O(n).
>
> I discovered how expensive vtable-limit-string is when working on a
> personal project of mine that creates vtables with hundreds of rows.
> According to profiler-report, it was by far the largest bottleneck.
Binary search will only work if adding or removing a character will
always change the result of string-pixel-width. But this is not true
in general, due to character composition and other Emacs display
features. Here's a simple example of such an issue:
(string-pixel-width "a")
=> 9
(string-pixel-width (concat "a" "́"))
=> 9
So adding a character doesn't affect the result of string-pixel-width,
in this case because the two characters will be displayed by a single
glyph that combines the base character 'a' and the acute accent.
Did you try your modified code in such situations, or did you only try
it with simple characters that never combine?
You can avoid the cost of this string metric by supplying your own global displayer function for the table or a column-specific displayer function.
Apropos timing as I've been spending some time with vtable and I have a bunch of bug fixes and a few enhancements coming. One will slow down that function a little more...vtable breaks under remapped fonts; e.g., when using text-scale-adjust so I've fixed that (I have some pixel adjustments left on the header which still gets out of alignment a little).