How can I speed up individual commands?

Question

When I call commands such as helm-apropos and custom Org agendas there is often a noticeable delay between the key sequence and the results presented. How can I speed up these commands to respond instantly to being called? I'm most interested in methods that can be applied to any Emacs commands, but optimizations for helm and org-mode would also be appreciated.

Please note - I am not asking about Emacs startup time. I would be happy for my Emacs startup to take 10x longer if I could make all Emacs commands instant.

Did you consider that there could be no intentional delay between the key stroke being registered and the command finishing, but just a lengthy computation going on? — wasamasa, Jul 20 '15 at 13:55
Do these commands take long time only first time they are called or every time? — Mark Karpov, Jul 20 '15 at 14:07
Org Agenda commands will take longer if there are skip functions and/or criteria that force evaluation of the header and the time-stamp. You can create your own custom org-agenda data gathering function to be more efficient. You can limit the `org-agenda-files` to only the ones you really need to query, or put everything in just one master file. Think of it like this: goto to the top of each file, then go to the first heading, then go to the time-stamp, then maybe skip, push data, then go to the next heading and repeat, push data, repeat until end of file, then move on to next file and . . — lawlist, Jul 20 '15 at 14:23
The function `org-agenda-list` will repeat the above-process for every day within the span -- `(while (setq d (pop day-numbers)) . . .` -- e.g., 31 days equals 31 loops through each `org-agenda-file` -- `(while (setq file (pop files)) (catch 'nextfile . . .` -- with the same dance of headline/time-stamp/skip-maybe. If you were to create your own custom function, you may wish to consider gathering all of the data in one fell swoop, and programmatically manipulate/sort all of the data rather than sweeping through the buffer multiple times. — lawlist, Jul 20 '15 at 14:45
The following link contains an example that bypasses `org-agenda-list` and goes straight to `org-agenda-get-day-entries` to gather data: http://emacs.stackexchange.com/a/12563/2287 If you choose to write your own function to programmatically manipulate/sort all the data rather than sweep through the buffer multiple times, then you'll need to modify the functions used by `org-agenda-get-day-entries` -- e.g., `org-agenda-get-todos`; `org-agenda-get-blocks`; `org-agenda-get-timestamps`; `org-agenda-get-sexps`; `org-agenda-get-scheduled`; `org-agenda-get-progress`; `org-agenda-get-deadlines`. — lawlist, Jul 20 '15 at 14:58
And, on a final note, you'll want to look at all three of the main gathering functions that launch the process that ultimately creates the `*Org Agenda*` buffer: `org-agenda-list`; `org-search-view`; and `org-tags-view`. If you are looking for a quicker workaround/solution that doesn't involve advanced `elisp` skills and days of programming; then, perhaps consider not using `*Org Agenda*` and instead use the functions that simply change the views of the master `org-mode` file being used -- e.g., hiding what you don't want to see. — lawlist, Jul 20 '15 at 15:14

abo-abo · Accepted Answer · 2015-07-21T07:30:31.253

helm-apropos is indeed pretty slow. I think it comes from joining 5 very large lists:

helm-apropos-function-list
;; =>
;; (helm-def-source--emacs-commands
;;  helm-def-source--emacs-functions
;;  helm-def-source--eieio-classes
;;  helm-def-source--eieio-generic
;;  helm-def-source--emacs-variables
;;  helm-def-source--emacs-faces
;;  helm-def-source--helm-attributes)

You can speed it up by generating one huge list right off the bat:

(defun helm-fast-apropos ()
      (interactive)
      (helm :sources
            '((name . "apropos: ")
              (candidates .
               (lambda ()
                 (all-completions "" obarray
                                  (lambda (x)
                                    (or
                                     ;; commands
                                     (commandp x)
                                     ;; functions
                                     (fboundp x)
                                     ;; EIEIO class
                                     (class-p x)
                                     ;; EIEIO generic
                                     (generic-p x)
                                     ;; variable
                                     (and (boundp x) (not (keywordp x))))))))
              (action . (lambda (x)
                        (setq x (intern x))
                        (cond ((boundp x)
                               (describe-variable x))
                              ((fboundp x)
                               (describe-function x))))))))

I also just had a quick look at the ivy equivalent of the above, I think it's around 0.2s faster:

(defun ivy-apropos ()
  (interactive)
  (ivy-read "apropos: "
            (all-completions "" obarray
                             (lambda (x)
                               (or
                                ;; commands
                                (commandp x)
                                ;; functions
                                (fboundp x)
                                ;; EIEIO class
                                (class-p x)
                                ;; EIEIO generic
                                (generic-p x)
                                ;; variable
                                (and (boundp x) (not (keywordp x))))))
            :keymap counsel-describe-map
            :preselect (counsel-symbol-at-point)
            :action (lambda (x)
                      (setq x (intern x))
                      (cond ((boundp x)
                             (describe-variable x))
                            ((fboundp x)
                             (describe-function x))))))

Edit: typical approach for caching

Very simple: store the whole collection into a variable, and hope that it doesn't need to be recomputed; recompute manually when needed (usually, when new packages are loaded):

(defvar helm-fast-apropos-cache nil)
(defun helm-update-apropos-cache ()
  (interactive)
  (setq helm-fast-apropos-cache
        (all-completions "" obarray
                         (lambda (x)
                           (or
                            ;; commands
                            (commandp x)
                            ;; functions
                            (fboundp x)
                            ;; EIEIO class
                            (class-p x)
                            ;; EIEIO generic
                            (generic-p x)
                            ;; variable
                            (and (boundp x) (not (keywordp x))))))))

(defun helm-fast-apropos ()
  (interactive)
  (helm :sources
        (quote ((name . "apropos: ")
                (candidates .
                            (lambda ()
                              (or helm-fast-apropos-cache
                                  (helm-update-apropos-cache))))
                (action . (lambda (x)
                            (setq x (intern x))
                            (cond ((boundp x)
                                   (describe-variable x))
                                  ((fboundp x)
                                   (describe-function x)))))))))

This approach saves only fraction of a second in this case, so it might not be worth it.

If the suggested speedup isn't enough, it's possible to add caching. It will be even faster, but has the drawback of having to refresh the cache sometimes. — abo-abo, Jul 20 '15 at 14:13
I would be very interested in caching. Is there a general approach that would allow me to cache any command? — Conor, Jul 20 '15 at 15:34
Well, if commands were to be purely functional, you could use memoization, but they are not. So, get in touch with the package authors and figure out what's going wrong for performance to be so bad. — wasamasa, Jul 20 '15 at 19:13
Thank you for the detail on caching. I couldn't get your helm apropos function to work, as I don't think you can supply action as an argument to `helm`. — Conor, Jul 20 '15 at 20:36
I was thinking of something similar for `helm-mode-recentf-open-files-compl`. Is there a way to call this function in the background and then kill it again when Emacs launches, so that when I call it manually later it, will be ready to go? — incandescentman, Jul 20 '15 at 22:50

How can I speed up individual commands?

1 Answers1

Edit: typical approach for caching