Open jgkamat opened 7 years ago
Can you provide actual hard numbers? It's otherwise hard to tell whether there's been an improvement by a change. I have one in mind that might help with this issue and am preparing a PR for it.
I'm not sure what you're asking for in terms of hard numbers, but:
- command-execute 817 67%
- call-interactively 817 67%
- funcall-interactively 690 57%
- evil-previous-line 305 25%
- evil-line-move 303 25%
- previous-line 303 25%
- line-move 303 25%
line-move-1 303 25%
- evil-next-line 289 23%
- evil-line-move 289 23%
- next-line 289 23%
- line-move 289 23%
line-move-1 289 23%
+ execute-extended-command 76 6%
+ minibuffer-complete-and-exit 20 1%
+ byte-code 127 10%
- redisplay_internal (C function) 260 21%
- eval 256 21%
- sml/generate-minor-modes 184 15%
- rm--mode-list-as-string-list 102 8%
- mapcar 53 4%
rm-format-mode-line-entry 37 3%
+ rm--propertize 12 0%
+ mapconcat 49 4%
+ sml/fill-width-available 74 6%
+ list 31 2%
sml/generate-modified-status 17 1%
+ eyebrowse-mode-line-indicator 12 0%
file-remote-p 4 0%
+ ... 60 4%
+ sp--save-pre-command-state 25 2%
+ evil--jump-hook 24 1%
+ evil-repeat-pre-hook 9 0%
evil-repeat-post-hook 4 0%
internal-timer-start-idle 4 0%
tooltip-hide 4 0%
I'm a bit confused at the profile, since it dosen't point to font-lock or redisplay as the primary curplit (maybe this is just my config, then). I have vim-style scrolling in my config, which is definetly making things worse.
When I made this issue originally, I wanted to try and play around with supporting lower font-lock levels and seeing if that helps with the problem at all, since I had similar problems with c++ mode, when I turned it up to the highest font-lock level.
I mean something like running font-lock-profiler-buffer
on the problematic buffer.
edit: Results:
Modified:
0 0 0% ("^" (0 form-feed--font-lock-face t))
10 0 0% ("[{}]" (0 font-lock-builtin-face))
12 0 0% ((lambda (_) (let (case-fold-search) (and (re-search-forward hl-todo-regexp nil t) (nth 8 (syntax-ppss))))) (1 (hl-todo-get-face) t t))
3 6 2% ("\\([a-zA-Z]\\{2\\}[A-Za-z0-9_-]*\\)\\( *\\(\"[A-Za-z0-9_-]*\"\\)\\)?:" (0 font-lock-type-face))
8 6 0% ("[@%][a-zA-Z]\\{2\\}[a-zA-Z0-9()+-]*" (0 font-lock-builtin-face))
2 58 2% ("\\([Vv][0-9]+\\):" (1 font-lock-function-name-face))
5 94 2% ("([a-zA-Z-]+!? +\\(?:[0-9]+\\|\\[\\(?::[a-zA-Z]+ ?\\)+\\]\\))" (0 font-lock-variable-name-face))
6 119 2% ("o[0-9]+" (0 font-lock-constant-face))
1 174 6% ("|" (0 font-lock-comment-face))
9 265 4% ("\\*[0-9]+" (0 font-lock-builtin-face))
11 532 8% ("[][]" (0 font-lock-builtin-face))
7 765 11% ("[<>]" (0 font-lock-constant-face))
4 2939 63% ("[a-gA-GrR]\\([-+_]*\\)\\([~.0-9/]*\\(?:m?s\\)?\\)" (1 font-lock-type-face) (2 font-lock-builtin-face))
Original:
3 6 3% ("\\([a-zA-Z]\\{2\\}[A-Za-z0-9_-]*\\)\\( *\\(\"[A-Za-z0-9_-]*\"\\)\\)?:" (1 font-lock-type-face))
7 6 0% ("\\([@%][a-zA-Z]\\{2\\}[a-zA-Z0-9()+-]*\\)" (1 font-lock-builtin-face))
12 21 2% ("\\([a-gA-GrR] *[-+]+\\)" (1 font-lock-preprocessor-face))
2 58 1% ("\\([Vv][0-9]+\\):" (1 font-lock-function-name-face))
4 94 2% ("\\(([a-zA-Z-]+!? +\\(\\([0-9]+\\)\\|\\(\\[\\(:[a-zA-Z]+ ?\\)+\\]\\)\\))\\)" (1 font-lock-variable-name-face))
5 119 2% ("\\(o[0-9]+\\)" (1 font-lock-constant-face))
1 174 3% ("\\(|\\)" (1 font-lock-comment-face))
9 265 5% ("\\(\\*[0-9]+\\)" (1 font-lock-builtin-face))
11 532 10% ("\\(\\[\\|\\]\\)" (1 font-lock-builtin-face))
6 765 15% ("\\(>\\|<\\)" (1 font-lock-constant-face))
8 2939 56% ("[a-gA-GrR][ +-]*\\([~.0-9 /]*\\(m?s\\)?\\)" (1 font-lock-builtin-face))
From this I can tell that if anything, you'd be best off to omit the most often applied rule for a less fancy font-lock level.
I originally tested alda-mode on small-ish files, but on larger files, it really slows down due to font lock. (such as https://github.com/joshhting/alda-music/blob/master/PotentialForAnything.alda)
I need to do a bit of work on the regexes, and see if I can get any performance improvements. If not, I'll look at reducing the default font lock level.