Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vim too slow on El Capitan using iTerm2 #670

Closed
fullofcaffeine opened this issue Oct 20, 2015 · 12 comments
Closed

Vim too slow on El Capitan using iTerm2 #670

fullofcaffeine opened this issue Oct 20, 2015 · 12 comments

Comments

@fullofcaffeine
Copy link

Possibly related to #661.

I'm on a 2014 MacBook Pro Retina, 2.8Ghz i7, 16GB of RAM, 1TB SSD.

On Yosemite, Vim's performance wasn't the best, but acceptable. I can't prove with benchmarks, but I can surely say that it became worst on El Capitan, for reasons I still can't understand.

It seems related to the rendering engine - there seem to be slight delay on input processing too - not sure if iTerm or Vim-related. I couldn't isolate the problem yet. It became so painful that I was forced (unwillingly) to abandon my yadr tmux development environment in favor of Sublime Text for now.

I'm willing to gather some additional data about this and try to isolate the issue when I have some free time, but I'd like to know if other people are experiencing the same, if so, does anyone know what could be causing this slowness?

@nkgm
Copy link

nkgm commented Nov 2, 2015

Just upgraded to El Capitan myself. Scrolling felt painfully sluggish - both iTerm2 and Apple's Terminal. I managed to track it down to lightline - disabling it made scrolling as smooth as vim -u NONE. After further experimentation, I replaced those fancy unicode glyphs in vim/settings/lightline.vim with plain old ASCII ones et voila! Scrolling is fast again!

This iTerm2 issue appears related (though old) but it's probably not, since Apple's own Terminal app is also affected.

@fullofcaffeine
Copy link
Author

Duplicate of: #661

@fullofcaffeine
Copy link
Author

@nkgm Hadn't seen this message. I'll try what you suggested. Thanks!

@fullofcaffeine
Copy link
Author

@nkgm The problem really seems to be Unicode glyphs, I wonder if it's related to Vim's rendering engine though?

@nkgm
Copy link

nkgm commented Dec 14, 2015

@fullofcaffeine that wasn't the case in Mavericks though. Couple more notes:

  • Even with unicode glyphs removed from lightline, scrolling performance deteriorates if NERDTree is open.
  • Half-screen horizontal splits help, as you would expect.
  • If all above fails, scroll in half-page increments (which I find myself use more often now and is a good habit anyway).

@romansalin
Copy link

I have the same problem. I removed separator and subseparator settings from settings/lightline.vim and it started to work fine. Does anybody know how it can be fixed keeping the unicode separators?

@nkgm
Copy link

nkgm commented Feb 27, 2017

Bit of a late update: it is easy to overlook setting the right font containing the glyphs used by the various statuslines in iTerm's Preferences/Profiles/Text. Make sure you set a Powerline font or similar.

There's a big gotcha
If you have the Powerline font installed but forgot to set the iTerm font, the
image glyphs will still show
(courtesy of macOS font fallback), but redrawing will be an order of magnitude slower!

@nkgm nkgm mentioned this issue Feb 27, 2017
@lfilho
Copy link
Collaborator

lfilho commented Mar 18, 2017

You think we could we close this by now, @fullofcaffeine @nkgm ?

@nkgm
Copy link

nkgm commented Mar 19, 2017

👍

@lfilho lfilho closed this as completed Jun 5, 2017
@kafeltz
Copy link

kafeltz commented Jul 10, 2017

@nkgm I confirm, uninstalling lightline make vim on macos fast again. On my linux, do not happen any minor slow rendering, strange.

@nkgm
Copy link

nkgm commented Jul 10, 2017

@kafeltz even though disabling lightline can help speed up TUI vim, it's usually not because lightline is slow, but due to its use of custom unicode glyphs in conjunction with an incorrect iTerm font setting. The root cause for me is outlined in #670 (comment).

@kafeltz
Copy link

kafeltz commented Jul 11, 2017

@nkgm you're right, It was basically a false positive info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants