Performance issues if org file contains too many tables

[llcc]

Hi @misohena. This package offers a whole world of possibility to step into the solution of combining visual-lines and trucated-lines. I love it.

Since I have used org-phscroll in my daily workflow, I see some performance issue if org file contains too many tables, especially long tables. It lags emacs when scrolling or switching the buffer, even opening files.

I could see some potential performance improvement on phscroll-update-current-line-display and its callees phscroll-truncate-string-to-width.

1. Since org table lines have same width, so I guess the internal varibale left-overflow left-len middle-shortage middle-len in phscroll-update-current-line-display can be calculated once and shared in the next calculation of the same phscroll area?

2. There might be another way to check and match the text property to get the right pos in phscroll-truncate-string-to-width, other than char-by-char scans?

Please have a look if you have any free time. Thanks again.

profile report:

      samples  %      Function
         669  57%     - eyebrowse-switch-to-window-config
         668  57%      - eyebrowse--load-window-config
         668  57%       - window-state-put
         667  57%        - window--state-put-2
         667  57%         - set-window-buffer
         667  57%          - phscroll-on-window-scroll
         667  57%           - phscroll-update-areas-in-window
         667  57%            - let*
         666  57%             - while
         666  57%              - phscroll-update-area-display
         666  57%               - if
         666  57%                - progn
         666  57%                 - let*
         665  57%                  - if
         665  57%                   - progn
         665  57%                    - phscroll-update-area-lines-display
         665  57%                     - save-excursion
         665  57%                      - while
         665  57%                       - let
         663  57%                        - if
         654  56%                         - progn
         640  55%                           - let*
         617  53%                            - phscroll-truncate-string-to-width
         615  52%                             - let*
         599  51%                              - while
         490  42%                               - let
         335  28%                                - phscroll-char-width-next
         280  24%                                 - let
         237  20%                                  - cond
         146  12%                                   - setq
          32   2%                                     + phscroll-get-overlay-at
           3   0%                                       get-text-property
          30   2%                                    + cons

[misohena]

Hi @llcc .

Thank you for your feedback. I have the same problem. It seems to be very slow if there are many tables in the folded place. I've profiled and improved speed before, but it's still slow.

Since org table lines have same width, so I guess the internal varibale left-overflow left-len middle-shortage middle-len in phscroll-update-current-line-display can be calculated once and shared in the next calculation of the same phscroll area?

I use Japanese characters. Those characters are counted as one character, but the display width is two characters. A character that uses the width of two characters in one character is called a full-width character. (For example, (length "あ") => 1, (string-width "あ") => 2, (char-width ?あ) => 2) (There are some special characters like TAB, but let's ignore them) Since we don't know where such characters appear on the line, we need to scan every character on every line. To make matters worse, full-width characters can straddle window boundaries (half of the characters go off the screen). In such a case, adjust by inserting a whitespace character without displaying the full-width character. left-overflow and middle-shortage are the number of whitespace characters to add. Its value can change from line to line. So I can't think of any more ways to speed up this part.

If you don't use full-width characters, you may be able to avoid scanning character by character and speed up as you wrote. There may be a way to add options and switch the processing method. (Unfortunately I can't use that option)

There are various other problems such as the layout collapsing, so when I have time, I will investigate more with them.

This comment is made with the help of Google Translate. I'm worried if it doesn't make sense.

Thank you.

[llcc]

@misohena Thanks for your reply. Indeed multi-language characters display is a unavoided problem. Like what you said, yes, neither do I could find any clue for further performance improvement.

Anyway, it's still bearable for working with my org file as usually, so I will keep using it. Thanks again.

[misohena]

I have improved fontify in org-phscroll.el.

This is to improve various display problems, but there may be some performance improvements as a side effect.

But it's still slow for very long tables. It wasn't too slow at first, but it got slower and slower as I scrolled. Especially simple fold / unfold and even moving is slower. After that, I forcibly removed all overlays for scrolling. Then it became normal speed.

(remove-overlays (point-min) (point-max) 'phscroll-left t) (remove-overlays (point-min) (point-max) 'phscroll-right t)

Too many overlays may be one of the reasons for the slowdown.