Needs performance improvements

[zk-phi]

magic-latex-buffer makes Emacs noticeably slow especially in large buffers.

[antoine-levitt]

This is not a very useful comment, but I agree. magic-latex-buffer is an awesome package, but it does make emacs slow and unresponsive. Fixing that would be great!

[zk-phi]

Hi, @antoine-levitt

magic-latex-buffer is an awesome package

thanks :)

I notice that searching TeX commands should be much more optimized (since it's possible).

[sanette]

I noticed one particularly slow operation: saving buffer. With my article of about 4000 lines, every time I save (which is in principle very often since I want to update the PDF), it can take several seconds to complete (5-20 sec). My laptop is a high-end XPS 13 with 16Go RAM, so I find it surprising. I'd be happy to help if one tells me in which direction to look for.

[doyougnu]

This got so bad with a journal paper that I had to disable the mode. For what it's worth I'm using spacemacs with emacsGcc. I ran the emacs profiler with mem+cpu and got this profile:

     83,191,591  69% - redisplay_internal (C function)
     82,063,988  68%  - jit-lock-function
     82,063,988  68%   - jit-lock-fontify-now
     82,063,988  68%    - apply
     82,062,932  68%     - jit-lock-fontify-now@ml/ad-jit-lock
     82,062,932  68%      - apply
     82,058,788  68%       - #<subr jit-lock-fontify-now>
     82,047,996  68%        - jit-lock--run-functions
     82,043,772  68%         - #<compiled 0x1f364355c030acfe>
     72,792,455  60%          - ml/jit-prettifier
     72,785,351  60%           - ml/search-regexp
      9,916,111   8%            - error-message-string
      9,916,111   8%             - substitute-command-keys
      1,310,176   1%              - #<compiled -0x1ddf10394b44eb47>
        562,848   0%               - kill-buffer
        228,096   0%                - #<compiled -0x1e3a55785b8e30ab>
        228,096   0%                 - spacemacs/useful-buffer-p
        228,096   0%                  - let
        228,096   0%                     or
            311   0%                make-closure
      9,533,840   7%              error
          6,704   0%             ml/remove-pretty-overlays
            400   0%             ml/overlay-at
      6,079,645   5%          + font-lock-fontify-region
      2,093,728   1%          + ml/jit-block-highlighter
        236,712   0%            org-ref-add-labels
            392   0%        + run-with-timer
        924,779   0%  + eval
         11,616   0%  + page-break-lines--update-display-tables
          5,280   0%  + winum--update
          4,224   0%  + which-key--hide-popup-on-frame-size-change
          4,216   0%  + eshell-refresh-windows
          3,168   0%  + window--adjust-process-windows
          3,168   0%  + mode-line-default-help-echo
          2,112   0%  + evil-refresh-cursor
     27,505,032  22% + timer-event-handler
      8,651,656   7% + command-execute
        287,136   0%   direnv--maybe-update-environment
         96,768   0% + preview-move-point
         93,984   0% + TeX-fold-post-command
         63,456   0% + winner-save-old-configurations
         55,440   0% + evil-escape-pre-command-hook
         36,081   0% + company-post-command
         24,488   0% + flycheck-handle-signal
          7,984   0% + flycheck-maybe-display-error-at-point-soon
          6,336   0% + jit-lock--antiblink-post-command
          3,840   0% + ml/post-command-function
          1,056   0% + evil-repeat-post-hook
          1,056   0%   flycheck-pos-tip-hide-messages
            713   0% + which-key--hide-popup
              0   0%   ...

so looks like most allocations and cpu time are spent in ml/jit-prettifier and specifically in ml/search-regexp

[doyougnu]

Also setting magic-latex-enable-pretty-symbols to nil removes the laggy performance issues. Which is probably not too surprising...