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

Powerline is slow on OSX #1280

Closed
dandrzejewski opened this issue Jan 22, 2015 · 21 comments
Closed

Powerline is slow on OSX #1280

dandrzejewski opened this issue Jan 22, 2015 · 21 comments

Comments

@dandrzejewski
Copy link

@dandrzejewski dandrzejewski commented Jan 22, 2015

I'm using powerline with the default configs. The prompts take a noticeable amount of time to appear on OSX.

I've tried both zsh and bash, and I am running powerline-daemon -q in .bash_profile/.zshrc.

I'm not 100% sure that this is a bug, but I'm willing to provide any information you need.

@ZyX-I
Copy link
Contributor

@ZyX-I ZyX-I commented Jan 22, 2015

I can recommend running

python -m cProfile -o /tmp/profile /path/to/powerline-daemon --replace

and posting the /tmp/profile file here after some time (note: use powerline-daemon --kill prior to posting it). Though most likely the problem is with either VCS branch segment or with configuration reloading.

Note: if you have some passwords in configuration (e.g. for email_imap_alert) I am not sure that profiling module will not save it somewhere, so they should be removed prior to profiling.

You can also try to find out what is the culprit by removing some segments from configuration. This is not helpful if culprit is configuration reloading though.

@etienned
Copy link

@etienned etienned commented Feb 12, 2015

I'm trying to use powerline 2.0 on OS X (10.10.1) with fish shell but it's really slow. I'm running powerline-daemon -q in my config.fish but I can see in top that each new prompt create a new python process. It looks like powerline didn't use is daemon.

@ZyX-I
Copy link
Contributor

@ZyX-I ZyX-I commented Feb 12, 2015

@etienned I guess this is #1297.

@ZyX-I ZyX-I added the e:macos label Feb 12, 2015
@ZyX-I
Copy link
Contributor

@ZyX-I ZyX-I commented Feb 12, 2015

@etienned It is also possible that you are using Python version of client (which is slowest of the three of them). Check out file "$(which powerline)": this may be Python script, shell script or an executable (ELF on linux, dunno how it is named in OS X).

@etienned
Copy link

@etienned etienned commented Feb 12, 2015

OK, I found the problem. I was installing powerline with pip but not with --user. When installing this way the powerline scripts were not install at all. After reinstalling the dev version with --user and fixed the $PATH, everything was fine.

I saw in the instructions that I should use --user but didn't know why so I tried without. Is there a way to install it globally?

Thanks for your work and time.

@ZyX-I
Copy link
Contributor

@ZyX-I ZyX-I commented Feb 12, 2015

@etienned They should work the either way. pip on OS X has its specific issues, including not working --user if you installed pip one way (there is a note on this in OS X installation instructions). Powerline has no code that is (not) run only if --user is enabled (in fact, I don’t even know how to do this), so if you want to work without --user then bug pip developers.

@ZyX-I ZyX-I closed this Feb 12, 2015
@etienned
Copy link

@etienned etienned commented Feb 12, 2015

Understood. It's definitely an installation problem where pip is the culprit. I will take some time a bit later to try to understand why pip didn't install /scripts/powerline* files when running globally. If I find something relevant I will let you know and pip developers.

@etienned
Copy link

@etienned etienned commented Feb 13, 2015

Just for the info. After investigation, I found that, when installing powerline globally with pip (with sudo and without --user) using stock python on OS X 10.10 (Yosemite), the powerline client is installed in /System/Library/Frameworks/Python.framework/Versions/2.7/bin/ instead of /usr/local/bin. I definitely don't know why but I'm not a packaging specialist. I'm using homebrew but not to install python at the moment.

@dandrzejewski
Copy link
Author

@dandrzejewski dandrzejewski commented Feb 26, 2015

Sorry for the delay. Here's a profile in this gist.

https://gist.github.com/dandrzejewski/821df90652f4c9b7ea7d

@ZyX-I
Copy link
Contributor

@ZyX-I ZyX-I commented Feb 26, 2015

@dandrzejewski I do not see you have done anything with the daemon. This profile is useless. If you have done something (I mean, display a few prompts) this means that you most likely have run into #1297 which is reported to prevent daemon from being ever used (effectively making powerline run an order of magnitude slower).

You need to start profiling, do what is slow a few times and only then stop the daemon. If this is what you have done try using shell (requires socat) or Python clients, they are slower, but not affected by #1297 or the like (no need to post the profile if with these clients everything is fine) (clients can be taken from client/ subdirectory of this repository, they AFAIR are not installed by pip if C compiler is available).

I am also wondering whether updating to post-#1297 (to 2.1 or current develop) powerline makes the issue disappear. This should be the easiest solution.

@dandrzejewski
Copy link
Author

@dandrzejewski dandrzejewski commented Feb 26, 2015

All I have to do is press enter a few times. It takes about a second to display each prompt. That's what I did to generate that profile.

I will review #1297.

On Feb 26, 2015, at 14:18, Nikolai Aleksandrovich Pavlov notifications@github.com wrote:

@dandrzejewski I do not see you have done anything with the daemon. This profile is useless. If you have done something (I mean, display a few prompts) this means that you most likely have run into #1297 which is reported to prevent daemon from being ever used (effectively making powerline run an order of magnitude slower).

You need to start profiling, do what is slow a few times and only then stop the daemon. If this is what you have done try using shell (requires socat) or Python clients, they are slower, but not affected by #1297 or the like (no need to post the profile if with these clients everything is fine) (clients can be taken from client/ subdirectory of this repository, they AFAIR are not installed by pip if C compiler is available).

I am also wondering whether updating to post-#1297 (to 2.1 or current develop) powerline makes the issue disappear. This should be the easiest solution.


Reply to this email directly or view it on GitHub.

@dandrzejewski
Copy link
Author

@dandrzejewski dandrzejewski commented Feb 26, 2015

Alright - updated powerline to version 2.1... fixed! Thanks everyone.

@jottr
Copy link

@jottr jottr commented Jul 12, 2015

I see powerline also slowing down my shell on OSX.

$ pip list | grep power
powerline-status (2.2)

zsh 5.0.8 (x86_64-apple-darwin14.3.0)

Here's a gist of my profiling attempt as @ZyX-I outlined above.
What I did to profile powerline was to spawn several new tmux windows, since that is when I am observing the slowdown.
Hope this helps.

@ZyX-I
Copy link
Contributor

@ZyX-I ZyX-I commented Jul 13, 2015

@jottr This gives me

% wget 'https://gist.github.com/jottr/a7967130c4e36731ac78/raw/1f4a1270750585cea9b665a1081331426abd8ef3/profile'
…
% pyprof2calltree -i profile -o calltree
Traceback (most recent call last):
  File "/usr/lib/python-exec/python2.7/pyprof2calltree", line 9, in <module>
    load_entry_point('pyprof2calltree==1.3.2', 'console_scripts', 'pyprof2calltree')()
  File "/usr/lib64/python2.7/site-packages/pyprof2calltree.py", line 279, in main
    kg = CalltreeConverter(pstats.Stats(options.infile))
  File "/usr/lib64/python2.7/pstats.py", line 81, in __init__
    self.init(arg)
  File "/usr/lib64/python2.7/pstats.py", line 95, in init
    self.load_stats(arg)
  File "/usr/lib64/python2.7/pstats.py", line 110, in load_stats
    self.stats = marshal.load(f)
ValueError: bad marshal data (unknown type code)

. Does gists accept uploading non-text data at all? I bet this is something stupid like CRNL changed to NL or unneeded NL at the end.

@jottr
Copy link

@jottr jottr commented Jul 13, 2015

@ZyX-I I've updated the original gist.
It looks like it was properly uploaded as a binary this time.

@N4M3Z
Copy link

@N4M3Z N4M3Z commented Aug 25, 2015

I am not sure if this is related but I did recently changed my python development environment on OS X and started using pyenv at which point I discovered that my shell noticeably slowed down when running powerline. After further investigation and testing I discovered that this is caused if one installs powerline into pyenv versions of python: this creates shims for powerline commands. On OS X, one possible solution is to install a separate version of python via homebrew for example and ensure that all powerline commands are sourced from there instead.
Also make sure, that pyenv refers the global python version to system:

pyenv global system

Please let me know if anyone else encountered this problem and could verify it. If so, this should be posted to pyenv and powerline issue tracking.

@DanielYWoo
Copy link

@DanielYWoo DanielYWoo commented Nov 28, 2017

2.6 is slow on my Macbook Pro, i7 16GB RAM, OSX 10.13.1

@N4M3Z
Copy link

@N4M3Z N4M3Z commented Dec 2, 2017

@DanielYWoo Are you using the python plugin from https://github.com/sorin-ionescu/prezto by any chance?

@DanielYWoo
Copy link

@DanielYWoo DanielYWoo commented Dec 5, 2017

@N4M3Z no, just bash

@N4M3Z
Copy link

@N4M3Z N4M3Z commented Jan 12, 2018

@DanielYWoo Try running:

powerline-daemon -q

before sourcing powerline config:

source $somewhere/powerline/powerline/powerline/bindings/bash/powerline.zsh

Powerline falls back to less performant solutions, if the daemon is not running.

@DanielYWoo
Copy link

@DanielYWoo DanielYWoo commented Jan 13, 2018

@N4M3Z N4
I put it before sourcing powerline config long time ago, but no use.

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

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.