jedi-vim is too too slow
fasterpython opened this issue · 46 comments
$vim test.py
import os, sys
os.
-- and then vim is fronzened for a few seconds.
I found it's really very slow while trying auto-comple by jedi-vim.
So, what can I do ?
OS: 64bit Debian/testing Dist
CPU: AMD IIx4 2.8GHz
Installed jedi-vim by vundle
Configured jedi-vim with:
"For jedi-vim:
"pip install jedi -- done
let g:jedi#autocompletion_command = "< tab>"
Well it might be slow the first time (on my 4 year old computer 1-1.5s), but it should be fast after that (50ms). Is that what you are getting?
Maybe we could create a simple command line tool to initially index/cache commonly used modules.
It could also try to do detection of large libraries like numpy and scipy...
Would it be enough to run a Script().complete() on the libraries from any python script to cache them?
Would it be enough to run a Script().complete() on the libraries from any python script to cache them?
Just use jedi.preload_module('os', 'sys', 'math', 'whatever_module_you_want')
Maybe we could create a simple command line tool to initially index/cache commonly used modules.
You would use that on every time VIM starts?
You would use that on every time VIM starts?
Nope, just as a tool that can be run after installing Jedi, so that initial imports aren't that slow.
Do you think that would be useful?
Let's first figure out what the problem is here. I'm not sure if that's the problem here. Generating a new os shouldn't be that slow. And if it's slow the first time, I don't even care a lot.
Same problem fo rme. For numpy the stall is the range of 10 seconds. The stall is not only the first time, it is every time. No stall for my own codebase (rather small compared to numpy).
vim 7.3.744
jedi 0.7.0
jedi-vim master today
linux
Any experiment i can do to give more info?
Apparently, i my case this is related to python-mode. After disabling python-mode jedi-vim runs fine. The issue is both with the latest master and develop branch of python-mode.
@fasterpython did you install python-mode as well?
I can confirm that with python-mode running too, dot-completion of SciPy is extremely slow (in the order of a couple of minutes), and not just the first time. I wonder if it has something to do with python-mode's rope completion...?
No, disabling rope-completion wasn't it. Disabling python-mode sompletely did the trick, though, so there is some conflict. Unfortunately, as I like the rest of python-mode but really like jedi's completion, too.
(I suggest removing the "not-reproducible" tag, as it is reproducible...)
I added conflict notes to the README. It would be good though to find out which parts are conflicting. Maybe we could fix it.
I'm pretty sure it's python-mode that causes the conflict. Jedi is really simple compared to python-mode. So if anyone has the time to nail it down? Probably there's some implicit rope call.
This does appear to be a rope problem, disabling rope in my vimrc (which I don't use anyway) seems to skirt the issue for me.
" Load rope plugin
let g:pymode_rope = 0
I got this problem too, jedi takes to much time to load and make my vim frozen , just for load "os" it take 15 to 20 seconds for my vim to react again.
Using pymode? Computer stats?
I came across this thread trying to solve the same apparent problem.
I'm on a System76 Gazelle Pro running Ubuntu 13.10, fully up to date. I can't pretend to be fully across the inner workings of vim and plug ins, but I've mostly followed advice off the web to use Vundle to install and update my jedi-vim and power line plugins.
Everything was working beautifully for a few months, but in the last few days, any full-stop (aka period, aka '.') freezes the system for a good 30-60 seconds or more -- even self.
The notice that I get at the bottom of the terminal in purple is:
[Pymode] Init Rope project: /home/jgehman/subdirectory
The comment above @alansaul re the rope guard seems to do the trick -- I now only get a moment's hesitation for the auto-completion, more or less as before.
Since all of this seems to be related to python-mode, I'm just closing it. @dbrgn added a note that jedi-vim conflicts with python-mode. Uninstall it or uninstall jedi-vim. At the moment it's apparently not possible to use them both. python-mode will start using Jedi at some point anyway (once refactoring is ready). At that point we can talk again.
Quoting myself from #250:
But it's not really a jedi-vim issue, since jedi-vim is at the moment a small and lightweight plugin, compared to python-mode. I think the problem is probably on the python-mode side, because they do a thousand different things (like debugging, etc).
i.e. you just have to decide at the moment which plugin to use. Jedi will introduce refactoring at some point, but we still need to improve the parser at the moment.
@davidhalter - thanks for the talk at EuroPython, I'm using jedi-vim as a result (and I hope you got to talk to Travis about possible Spyder integration).
I'm successfully using jedi-vim and python-mode. For python-mode I've disabled rope by adding let g:pymode_rope = 0 to my .vimrc. This leaves other python-mode features (e.g. line numbering, pyflakes warnings) enabled. With rope disabled and jedi-vim running I can import scipy; scipy.<completions appear> with no delay, if I enable rope then I have a 1 second delay.
I'll continue to experiment with both tools (with rope disabled) and report here if I have further issues.
I do not have python-mode installed in vim, however jedi-vim is causing a noticeable slowdown when it is loaded. VIM 7.4, Python 3.4, latest jedi & jedi-vim. Whenever I am in editing mode in VIM with jedi-vim installed, there is a delay in my typing, which makes development frustrating to say the least. It is less than a second per-key-typed, I'd guess around 100 - 200ms delay. It exists even when I have absolutely no other plugins set up for VIM besides jedi-vim (and Pathogen). If I do not install jedi-vim, I do not experience this delay at all.
I can provide other details as needed.
@xlorepdarkhelm Just disable show_call_signatures and you're done. It's a known issue. That's the solution, if you don't want that minor delay.
@xlorepdarkhelm Just disable show_call_signatures and you're done. It's a known issue. That's the solution, if you don't want that minor delay.
I can confirm I got a little bit added pep by omitting call signatures. Going to a/b test it a bit to see if it's worth keeping on. Signatures may not add enough value if there's a road bump at every parenthesis.
@davidhalter That's the solution, thanks.
Guys, the problem on my system seems to be related to Pymode's folding.
let g:pymode_folding=0
seems to make the difference (unlike setting rope to 0/1).
I got to try this after reading this:
python-mode/python-mode#523
It seems pymode's folding has issues of it's own. Alternative folding plugins are recommended, I've yet to try them.
Just disable show_call_signatures and you're done. It's a known issue. That's the solution, if you don't want that minor delay.
@davidhalter Is there a way to fix that issue? I really like call signatures, they are very useful to me.
davidhalter/jedi#385 would probably solve it.
I am having the same slowness issue as reported here under sygwin. I am using a laptop with an I7 cpu and performance or memory does not seem to be the cause. It takes about 20 seconds or so for jedi vim to respond. Even after the autocomplete loads, if i leave vim without entering anything for a bit say a min or so, the autocomplete takes again for ever to load.
For example:
os. <<< about 20 seconds
os.close << fast
[wait a min or so]
os. <<< about 20 seconds
The only modules I have installed are:
Vundle
jedi-vim
Vim version:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 8 2015 00:46:23)
Included patches: 1-801, 803-808, 810-891
Compiled by cygwin@cygwin.com
Any insight would be appreciated.
Thanks,
Constantine.
I have similar issue under Cygwin, native windows and Linux has no such issue.
I tried latest code.
I think problem is pymode's virtualenv. Disable rope and virtualenv plugin solve the problem.
For me, the problem was pymode's folding, as suggested by @flor385. let g:pymode_folding = 0 solved the issue for me.
On Arch Linux with the current git download of Neovim built as "Release", can confirm that this is still a problem. Deocomplete-jedi and pythonmode installed, deocomplete set up and python-mode only installed with no prior usage. The "let g:pymode_rope = 0" trick worked for me. Not sure why this is still a problem after 3 years or so.
Edit: Okay, I see why. Good point, @blueyed.
Not sure why this is still a problem after 3 years or so.
Apparently nobody cares enough to debug and fix it?!
Emacs-jedi is far more smooth than jedi-vim.
Can we use a timer polling method to avoid http timeout waiting ?
see here, #654
jedi-vim is not using http at all.
I was also getting an unacceptable delay with numpy so I dug into the code and found out that jedi.parser.cache.save_module was consuming a significant amount of time with use_filesystem_cache=True (default, perhaps to save memory usage?).
The table below is what I measured on my Ubuntu 14.04 with Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz & SSD, in milliseconds.
| use_filesystem_cache | True | False |
|---|---|---|
| os | 380 | 220 |
| numpy | 7000 | 2100 |
| scipy | 7000 | 2150 |
| pandas | 450 | 250 |
import jedi
s = 'import numpy ; numpy.'
script = jedi.Script(s, 1, len(s), '')
script.completions()That said, I guess I should also look for async approaches like davidhalter/jedi#385 or YCM.
@sergeant-wizard
deoplete / deoplete-jedi is also a good option, but requires you to use Neovim.
And, really, if you're going to be using vim, you should use Neovim.
@blueyed neovim made good progress recently. As a windows user, I really like to switch from gvim.
nvim-qt is far more better than gvim (no flicker when scrolling).
If neovim/neovim#6695 can be solved, I think most windows users will like to choose nvim-qt rather than gvim.
After the recent refactor of YouCompleteMe: ycm-core/YouCompleteMe#2657, jedi seems no delay and works fine now with the latest ycm.
I don't know if this is important, but my problem was with deoplete, not youcompleteme.
deoplete needs a refactor too.
So, are you saying this bug is still an issue with deoplete but not ycm?
Sure, I can confirm that.
because I have suggested ycm how to refactor before:
@skywind3000
deoplete is async, and uses timers?!
At least when I last tried it, this problem only occurs with deoplete when python-mode is installed. It is some problem with rope, whatever that is, and can be fixed by disabling rope.
Not sure why this is still a problem after 3 years or so.
Apparently nobody cares enough to debug and fix it?!
3 years later i still have problems regarding speed. python-mode not installed
importing the pytorch library and with that i am waiting like 10 seconds....
same issue, pytorch takes forever