Kenny Chen <[email protected]> writes: > For the hackathon, I'm working on improving table alignment performance > since I've seen tables be slow in my day-to-day. > > I have a couple patches, with which I see nearly 4x improvement on > Ihor's long table test case (~23k rows, went from ~41 seconds -> ~11 > seconds): > https://0x0.st/KOVt.txt
Thanks! I tested the patches with native compilation + Emacs 31: - origin/main :: (17.418275515 140 8.199356909), (18.685597039 141 8.807462903), (17.400398723 141 8.187608776) - patch 1 :: (14.722655296 109 6.578058977), (14.464926977 110 6.6344314429999995), (14.413020401 110 6.5618406) - patch 2 :: (14.217771401999999 105 6.3110911220000006), (14.081379752 105 6.300228085), (14.042596573 105 6.287324997000001) - patch 3 :: (8.408496028 69 4.603161624), (8.360843182 69 4.60719636), (8.270580451999999 69 4.538656109000001) - patch 4 :: (8.258642567 68 4.521816169), (8.215847934000001 68 4.506579918), (8.248972890000001 68 4.530805382) Each of the patches gives a noticeable improvement in speed on the example table. The patches are mostly ok, with few minor comments: > -(defun org-table--align-field (field width align) > +(defun org-table--align-field (field width align &optional field-width) > "Format FIELD according to column WIDTH and alignment ALIGN. > FIELD is a string. WIDTH is a number. ALIGN is either \"c\", > \"l\" or\"r\"." > - (let* ((spaces (- width (org-string-width field nil 'org-table))) > + (let* ((spaces (- width (or field-width (org-string-width field nil > 'org-table)))) The new argument should be documented in the docstring. Also, please announce changes in the function arguments in etc/ORG-NEWS. > +(defvar org-string-width--old-emacs (version< emacs-version "28")) Please add a docstring to this new variable. > These patches improve org-string-width performance (fewer allocations) > and cache its results in org-table-align. The actual improvement you'll > see depends on how many cells have the same text (for cache hits), but I > expect ~2x improvement in the worst cases. I think there's still quite a > lot of room for optimization here. Likely yes. Further work on this or other performance bottlenecks (including table formula calculation) would be welcome. Including beyond the hackathon. > I only dabble in Elisp; comments and modifications are welcome... And I > will complete the FSF copyright waiver. Let me know if you need any assistance with FSF copyright. Note that the copyright clerk from FSF should reply within one week. If not, let me know. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
