search

syl20bnr / spacemacs

A community-driven Emacs distribution - The best editor is neither Emacs nor Vim, it's Emacs *and* Vim!
http://spacemacs.org
GNU General Public License v3.0
23.66k stars 4.89k forks source link

Evil commands are very slow #8315

Closed zeronone closed 7 years ago

zeronone commented 7 years ago

Delete commands such as dw, dd are very slow (p etc show a similar lag)

Profiling several consecutive dw, and dd commands (in normal vim mode) show the following. It seems the helm command is triggered in between and takes a long time.

- command-execute                                                1459  80%
 - call-interactively                                            1459  80%
  - byte-code                                                     972  53%
   - helm-M-x-read-extended-command                               812  44%
    - helm-comp-read                                              811  44%
     - helm                                                       806  44%
      - apply                                                     806  44%
       - helm                                                     806  44%
        - apply                                                   806  44%
         - helm-internal                                          806  44%
          + helm-read-pattern-maybe                               764  42%
          + helm-initialize                                        37   2%
          + helm-display-buffer                                     4   0%
          + #<compiled 0x43ed166b>                                  1   0%
     + helm-make-source                                             5   0%
   + evil-operator-range                                          159   8%
  - funcall-interactively                                         487  26%
   + helm-M-x                                                     259  14%
   - evil-delete                                                  109   6%
    - evil-yank                                                   104   5%
     - evil-yank-lines                                            104   5%
      - kill-new                                                  104   5%
       + pbcopy-selection-value                                    60   3%
       + pbcopy-select-text                                        44   2%
    + evil-first-non-blank                                          4   0%
   + evil-ex                                                       66   3%
   + evil-mouse-drag-region                                        42   2%
   + evil-next-line                                                 3   0%
   + undo-tree-undo                                                 3   0%
   + profiler-report-toggle-entry                                   1   0%
   + evil-previous-line                                             1   0%
+ redisplay_internal (C function)                                 155   8%
+ ...                                                             138   7%

System Info :computer:

laduke commented 7 years ago

My emacs was being slow. I mostly noticed it in elm mode. I was on the railwaycat brew emacs. Last night I switched to brew emacs-plus. And for some reason it's faster now. I don't know if it's just from restarting emacs, which I go for long stretches of time without doing.

How did you do the profiling?

I post because we have similar systems.

System Info :computer:

zeronone commented 7 years ago

@laduke You can start the profile with M-x profiler-start and perform the actions (in my case, several dd, dw commands); and get the report with M-x profiler-report.

zeronone commented 7 years ago

The problem was solved for me after installing emacs-plus from homebrew/d12frosted. So I will close the issue.

zeronone commented 7 years ago

Nevertheless the problem persists when used with emacs --daemon && emacsclient -c

braham-snyder commented 7 years ago

I ran into this issue periodically in the past--it would go away after restarting emacs with <leader> q r (and reappear if I quit with, e.g., <leader> q q), which suggests it could have been layout-related, maybe? In any case, I haven't run into this issue again in quite a while, but I'm not sure why. Additionally, I vaguely remember it disappearing after I'd fix seemingly-unrelated, minor errors in my user-config (non-breaking errors that showed up in the *Messages* buffer). I never quite figured it out. For what it's worth, here's my system information (though, again, I haven't run into this issue in a while):

System Info :computer:

braham-snyder commented 7 years ago

@zeronone this may actually be symptomatic of a relatively pernicious issue: your $SHELL's non-interactive configuration may be taking that long to run.

For example, with fish (I don't remember the particulars of bash/zsh interactive vs. non-interactive configuration files), adding sleep 5 to my config.fish reproduces this issue (each call to, e.g., dd takes 5+ seconds). Again with fish, the solution is to wrap sleep 5 (or, in practice, anything in your config.fish that you only need in interactive shells) in an if status is-interactive check.

I'm not absolutely positive the behavior I've just described is expected behavior: while I don't know a bunch about this area of programming, this was definitely surprising to me (why would evil/emacs need to call non-interactive shell configuration every time I, e.g., attempt to delete a line with dd?).

zeronone commented 7 years ago

@braham-snyder I guess you found the root cause. I removed the following line from ~/.zshenv and everything is fast again (when I run emacs with emacs --daemon && emacsclient -c). 

NVM_DIR=$HOME/.nvm
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"  # This loads nvm

But I don't know why Evil commands get to run this file. Maybe related to exec-path-from-shell.

thealmightygrant commented 7 years ago

If you have omf, oh-my-fish, installed. Then the solution to this issue is to wrap the file ~/.config/fish/omf.fish in if status --is-interactive like so:

if status --is-interactive
  # Path to Oh My Fish install.
  set -q XDG_DATA_HOME
    and set -gx OMF_PATH "$XDG_DATA_HOME/omf"
    or set -gx OMF_PATH "$HOME/.local/share/omf"

  # Load Oh My Fish configuration.
  source $OMF_PATH/init.fish
end

I think @braham-snyder had the right idea to fix this issue (if you have fish shell installed).

alxest commented 6 years ago

I have been suffered for the same issue. The problem was reproduced with: CentOS Linux release 7.4.1708, GNU Emacs 24.3.1, evil 20160818, mac 10.12.6 (16G29), GNU Emacs 25.1.1, evil 20160827

scrotty commented 2 years ago

Be sure to check whether you're using evil-goggles. I spent 30 minutes - including finding this issue and messing with my fish shell - only to learn I was using a package specifically designed to slow and make visible file changes triggered by evil bindings! 🤦