davidhalter / jedi-vim

Using the jedi autocompletion library for VIM.
MIT License
5.28k stars 370 forks source link

jedi-vim is too too slow #163

Closed fasterpython closed 10 years ago

fasterpython commented 11 years ago
$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>"

davidhalter commented 11 years ago

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?

dbrgn commented 11 years ago

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?

davidhalter commented 11 years ago

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?

dbrgn commented 11 years ago

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?

davidhalter commented 11 years ago

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.

lodagro commented 11 years ago

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?

lodagro commented 11 years ago

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.

davidhalter commented 11 years ago

@fasterpython did you install python-mode as well?

thriveth commented 11 years ago

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...?

thriveth commented 11 years ago

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...)

dbrgn commented 11 years ago

I added conflict notes to the README. It would be good though to find out which parts are conflicting. Maybe we could fix it.

davidhalter commented 11 years ago

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.

alansaul commented 10 years ago

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
jbeja commented 10 years ago

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.

davidhalter commented 10 years ago

Using pymode? Computer stats?

ghost commented 10 years ago

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.

davidhalter commented 10 years ago

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.

ianozsvald commented 10 years ago

@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.

xlorepdarkhelm commented 9 years ago

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.

davidhalter commented 9 years ago

@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.

tony commented 9 years ago

@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.

diabloneo commented 9 years ago

@davidhalter That's the solution, thanks.

florijanstamenkovic commented 9 years ago

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: https://github.com/klen/python-mode/issues/523

It seems pymode's folding has issues of it's own. Alternative folding plugins are recommended, I've yet to try them.

balta2ar commented 8 years ago

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 commented 8 years ago

https://github.com/davidhalter/jedi/issues/385 would probably solve it.

samaklis commented 8 years ago

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.

gerryqd commented 8 years ago

I have similar issue under Cygwin, native windows and Linux has no such issue.

I tried latest code.

xuyuheng commented 8 years ago

I think problem is pymode's virtualenv. Disable rope and virtualenv plugin solve the problem.

kroq-gar78 commented 8 years ago

For me, the problem was pymode's folding, as suggested by @flor385. let g:pymode_folding = 0 solved the issue for me.

vatrat commented 7 years ago

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.

blueyed commented 7 years ago

@vatrat

Not sure why this is still a problem after 3 years or so.

Apparently nobody cares enough to debug and fix it?!

skywind3000 commented 7 years ago

Emacs-jedi is far more smooth than jedi-vim.

Can we use a timer polling method to avoid http timeout waiting ?

see here, https://github.com/davidhalter/jedi-vim/issues/654

davidhalter commented 7 years ago

jedi-vim is not using http at all.

sergeant-wizard commented 7 years ago

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 https://github.com/davidhalter/jedi/issues/385 or YCM.

blueyed commented 7 years ago

@sergeant-wizard deoplete / deoplete-jedi is also a good option, but requires you to use Neovim.

vatrat commented 7 years ago

And, really, if you're going to be using vim, you should use Neovim.

skywind3000 commented 7 years ago

@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 https://github.com/neovim/neovim/issues/6695 can be solved, I think most windows users will like to choose nvim-qt rather than gvim.

skywind3000 commented 7 years ago

After the recent refactor of YouCompleteMe: https://github.com/Valloric/YouCompleteMe/pull/2657, jedi seems no delay and works fine now with the latest ycm.

vatrat commented 7 years ago

I don't know if this is important, but my problem was with deoplete, not youcompleteme.

skywind3000 commented 7 years ago

deoplete needs a refactor too.

vatrat commented 7 years ago

So, are you saying this bug is still an issue with deoplete but not ycm?

skywind3000 commented 7 years ago

Sure, I can confirm that. because I have suggested ycm how to refactor before:

https://github.com/Valloric/YouCompleteMe/issues/2500

blueyed commented 7 years ago

@skywind3000 deoplete is async, and uses timers?!

vatrat commented 7 years ago

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.

LeErnst commented 1 year ago

@vatrat

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....

WuTheFWasThat commented 1 year ago

same issue, pytorch takes forever