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

Shell prompt has very notable delay #104

Closed
ZyX-I opened this Issue Jan 22, 2013 · 10 comments

Comments

Projects
None yet
3 participants
@ZyX-I
Contributor

ZyX-I commented Jan 22, 2013

Subj. I can now suggest two things: first, use one call for both PS1 and RPS1 (with eval used to get the result back). It will get rid of the delay between times when PS1 and RPS1 is shown, but won’t get rid of the issue.

Second, make script not evaluated each time prompt is shown. If nothing useful is suggested here or I fail to invent better idea I will probably write a PR with something based on zsh/zpty (overkill, but I see no better options). Bash users will have to invent something on their own.

Though I already though about another idea: writing zsh/zpython C module that will provide commands similar to python/python3 in vim (meaning that python is initialized once module is loaded).

Note: time shows the following for PS1 side:

0,07s user 0,01s system 93% cpu 0,086 total

. I guess “notable delay” consists almost solely of python initialization and I notice it even is PS1 is simple python -c 'print "abc"' (0,02s user 0,00s system 91% cpu 0,026 total).

@Lokaltog

This comment has been minimized.

Show comment
Hide comment
@Lokaltog

Lokaltog Jan 22, 2013

Member

Yeah, I've noticed this as well.

I don't have deep knowledge about threading and all that stuff, but could it be an idea to have a global Powerline daemon which reads all the config files for all the extensions on startup, caches it and serves it to vim, tmux, shells, etc. on demand? The daemon could maybe create a couple of Unix sockets that can be used for communication so we can just cat the statuslines/prompts to avoid starting Python over and over again? Again, I don't know all the pitfalls of doing this and I'm sure you've thought about it already but I'd like to know your thoughts on this anyways.

Edit: Just saw your comment on stackoverflow, and I can see how the socket solution can be an issue.

Member

Lokaltog commented Jan 22, 2013

Yeah, I've noticed this as well.

I don't have deep knowledge about threading and all that stuff, but could it be an idea to have a global Powerline daemon which reads all the config files for all the extensions on startup, caches it and serves it to vim, tmux, shells, etc. on demand? The daemon could maybe create a couple of Unix sockets that can be used for communication so we can just cat the statuslines/prompts to avoid starting Python over and over again? Again, I don't know all the pitfalls of doing this and I'm sure you've thought about it already but I'd like to know your thoughts on this anyways.

Edit: Just saw your comment on stackoverflow, and I can see how the socket solution can be an issue.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jan 23, 2013

Contributor

For vim you are going to lose a lot on IPC (you need to query vim about some things) or have some computations done in the vim instance (which defeats the point) for nothing: you are not saving yourself from launching interpreter because it is launched only once.

For tmux it is not making much sense as unlike vim tmux does not block me from using itself while statusline is being computed.

For shell it is probably a good choice, but I am not familiar with any IPC except for pipes (and shared memory via multiprocessing.Value). Also I am afraid of GCing stale sockets (it is doable, I already have experience of writing that stuff, but variants I wrote always looked like a hack for me). The ideal variant is zsh/zpython module.

Contributor

ZyX-I commented Jan 23, 2013

For vim you are going to lose a lot on IPC (you need to query vim about some things) or have some computations done in the vim instance (which defeats the point) for nothing: you are not saving yourself from launching interpreter because it is launched only once.

For tmux it is not making much sense as unlike vim tmux does not block me from using itself while statusline is being computed.

For shell it is probably a good choice, but I am not familiar with any IPC except for pipes (and shared memory via multiprocessing.Value). Also I am afraid of GCing stale sockets (it is doable, I already have experience of writing that stuff, but variants I wrote always looked like a hack for me). The ideal variant is zsh/zpython module.

@Lokaltog

This comment has been minimized.

Show comment
Hide comment
@Lokaltog

Lokaltog Jan 23, 2013

Member

True, it would only have a big benefit for the shell. I don't like that it's limited to zsh though, but it's definitely better than nothing. I don't know anything about zsh/zpython modules so you'd have to implement this.

Member

Lokaltog commented Jan 23, 2013

True, it would only have a big benefit for the shell. I don't like that it's limited to zsh though, but it's definitely better than nothing. I don't know anything about zsh/zpython modules so you'd have to implement this.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jan 23, 2013

Contributor

@Lokaltog There is no zsh/zpython module. But taking if_py* from vim and some module sources it should be relatively easy to create one. I will ask about this on zsh mailing list (I mean, whether it will be included if I write it).

Contributor

ZyX-I commented Jan 23, 2013

@Lokaltog There is no zsh/zpython module. But taking if_py* from vim and some module sources it should be relatively easy to create one. I will ask about this on zsh mailing list (I mean, whether it will be included if I write it).

@Lokaltog

This comment has been minimized.

Show comment
Hide comment
@Lokaltog

Lokaltog Jan 23, 2013

Member

Nice, thanks!

Member

Lokaltog commented Jan 23, 2013

Nice, thanks!

ZyX-I added a commit to ZyX-I/powerline that referenced this issue Jan 28, 2013

Added support for zsh/zpython
No delay now, experimental, requires zpython zsh branch from https://bitbucket.org/ZyX_I/zsh
Needs some improvements
Ref powerline#104
@Lokaltog

This comment has been minimized.

Show comment
Hide comment
@Lokaltog

Lokaltog Feb 7, 2013

Member

Closing this as the zpython stuff works so well.

Member

Lokaltog commented Feb 7, 2013

Closing this as the zpython stuff works so well.

@Lokaltog Lokaltog closed this Feb 7, 2013

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Feb 7, 2013

Contributor

It was not merged into mainstream. In fact, I still have not received any reply on the mailing list.

Contributor

ZyX-I commented Feb 7, 2013

It was not merged into mainstream. In fact, I still have not received any reply on the mailing list.

@Lokaltog

This comment has been minimized.

Show comment
Hide comment
@Lokaltog

Lokaltog Feb 7, 2013

Member

I'm fine with pointing zsh users to your branch until the zsh maintainers have made a decision, but if you disagree I can open this issue again?

Member

Lokaltog commented Feb 7, 2013

I'm fine with pointing zsh users to your branch until the zsh maintainers have made a decision, but if you disagree I can open this issue again?

ZyX-I added a commit to ZyX-I/powerline that referenced this issue Feb 7, 2013

Added note about zpython branch.
TODO: to be removed after (if) zsh maintainers accept the patch
Ref powerline#104

Lokaltog added a commit that referenced this issue Feb 8, 2013

Add note about zpython branch
TODO: To be removed after (if) zsh maintainers accept the patch.

Refs #104.
@mindfulmonk

This comment has been minimized.

Show comment
Hide comment
@mindfulmonk

mindfulmonk Mar 13, 2013

ZyX-I any news if your branch going to be merged with upstream zsh?

mindfulmonk commented Mar 13, 2013

ZyX-I any news if your branch going to be merged with upstream zsh?

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Mar 13, 2013

Contributor

@janukevic No news. But I am working on adding python3 support to it (current status: it was added successfully (all but reloading tests pass), but crashes when trying to load unloaded zpython module). When it is finished I will bump the old thread and ask about status.

Note about support: unlike Bram I am not willing to maintain that very long list of symbols loaded from dlopened library. Thus you will have to choose python version you are willing to work with, compiling in both python2 and python3 is not possible.

Branch in question was recently rebased.

Contributor

ZyX-I commented Mar 13, 2013

@janukevic No news. But I am working on adding python3 support to it (current status: it was added successfully (all but reloading tests pass), but crashes when trying to load unloaded zpython module). When it is finished I will bump the old thread and ask about status.

Note about support: unlike Bram I am not willing to maintain that very long list of symbols loaded from dlopened library. Thus you will have to choose python version you are willing to work with, compiling in both python2 and python3 is not possible.

Branch in question was recently rebased.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment