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

Shell prompt has very notable delay #104

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

Shell prompt has very notable delay #104

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

Comments

@ZyX-I
Copy link
Contributor

@ZyX-I 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
Copy link
Member

@Lokaltog 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
Copy link
Contributor Author

@ZyX-I 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
Copy link
Member

@Lokaltog 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
Copy link
Contributor Author

@ZyX-I 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
Copy link
Member

@Lokaltog Lokaltog commented Jan 23, 2013

Nice, thanks!

ZyX-I added a commit to ZyX-I/powerline that referenced this issue Jan 28, 2013
No delay now, experimental, requires zpython zsh branch from https://bitbucket.org/ZyX_I/zsh
Needs some improvements
Ref powerline#104
@Lokaltog
Copy link
Member

@Lokaltog Lokaltog commented Feb 7, 2013

Closing this as the zpython stuff works so well.

@Lokaltog Lokaltog closed this Feb 7, 2013
@ZyX-I
Copy link
Contributor Author

@ZyX-I 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
Copy link
Member

@Lokaltog 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
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
TODO: To be removed after (if) zsh maintainers accept the patch.

Refs #104.
@mindfulmonk
Copy link

@mindfulmonk mindfulmonk commented Mar 13, 2013

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

@ZyX-I
Copy link
Contributor Author

@ZyX-I 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants