jedi-vim causes lag in insert mode

[alicee]

I'm experiencing an irritating lag in insert mode, i.e. it takes a long (up to 0.5 seconds) time for a character to appear after I type it. One of the files I'm having this issue with is ~800 lines of code, so I wouldn't expect mere size to be the root cause? Removing jedi-vim also removes the lag, so I assume it must have something to do with this plugin. Completely removing my .vimrc doesn't seem to have any effect. This happens with supertab, autocomplpop, and also when both of them are disabled.

I profiled some of the insert-mode madness like this:

:profile start profile.log
:profile func *
:profile file *
" At this point do slow actions
:profile pause
:noautocmd qall!

and it seems like _vim_exception is being called rather often (given that I only inserted ~80 chars):

FUNCTION  jedi#_vim_exceptions()
Called 313 times
Total time:   0.014491
 Self time:   0.014491

count  total (s)   self (s)
  313              0.002117     let l:result = {}
  313              0.000798     try
  313              0.000745         if a:is_eval
  261              0.002488             let l:result.result = eval(a:str)
  261              0.000370         else
   52              0.002304             execute a:str
   52              0.000199             let l:result.result = ''
   52              0.000060         endif
  313              0.000390     catch
                                    let l:result.exception = v:exception
                                    let l:result.throwpoint = v:throwpoint
                                endtry
  313              0.000692     return l:result

Perhaps this is an issue with vim-jedi interacting with one of my other plugins, so here's the global summary:

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
    1   0.238969   0.000101  <SNR>20_UpdateErrors()
    1   0.231162   0.000322  <SNR>20_CacheErrors()
    2   0.229969   0.000126  SyntaxCheckers_python_GetLocList()
    2   0.229843   0.000092  SyntasticMake()
    2   0.229751   0.011751  SyntasticLocalMake()
    3   0.053375   0.052994  <SNR>39_RunPyflakes()
    1   0.019087             GetPythonIndent()
  313   0.014491             jedi#_vim_exceptions()
    4   0.012549   0.000207  <SNR>20_OSSupportsShellpipeHack()
    2   0.012342   0.000284  <SNR>20_uname()
   56   0.008552             <SNR>25_Highlight_Matching_Pair()
    1   0.007604   0.000098  <SNR>20_RedrawErrors()
    1   0.005281   0.000056  <SNR>20_RefreshSigns()
    1   0.005174   0.005001  <SNR>20_SignErrors()
    1   0.001678   0.000034  <SNR>20_AutoToggleLocList()
    1   0.001599   0.000316  <SNR>20_ShowLocList()
    1   0.000686   0.000206  SyntasticCheckable()
    1   0.000568   0.000492  <SNR>11_LoadFTPlugin()
    1   0.000495   0.000329  <SNR>5_SynSet()
    5   0.000444   0.000387  <SNR>20_FilterLocList()

FUNCTIONS SORTED ON SELF TIME
count  total (s)   self (s)  function
    3   0.053375   0.052994  <SNR>39_RunPyflakes()
    1              0.019087  GetPythonIndent()
  313              0.014491  jedi#_vim_exceptions()
    2   0.229751   0.011751  SyntasticLocalMake()
   56              0.008552  <SNR>25_Highlight_Matching_Pair()
    1   0.005174   0.005001  <SNR>20_SignErrors()
    1   0.000568   0.000492  <SNR>11_LoadFTPlugin()
    5   0.000444   0.000387  <SNR>20_FilterLocList()
    1   0.000495   0.000329  <SNR>5_SynSet()
    1   0.231162   0.000322  <SNR>20_CacheErrors()
    1   0.001599   0.000316  <SNR>20_ShowLocList()
    2   0.012342   0.000284  <SNR>20_uname()
    3              0.000239  <SNR>39_ActivatePyflakesQuickFixWindow()
    1   0.000279   0.000236  <SNR>20_HightlightErrors()
    1              0.000231  <SNR>15_addtomrufs()
    3              0.000216  SyntasticAddToErrors()
    4   0.012549   0.000207  <SNR>20_OSSupportsShellpipeHack()
    1   0.000686   0.000206  SyntasticCheckable()
   13              0.000159  <SNR>20_LocList()
    1   0.000233   0.000147  <SNR>20_LoadChecker()

Any idea where to look or how to debug this?

[davidhalter]

Please try let g:jedi#show_call_signatures = "0"

[alicee]

That does indeed eliminate the input lag.

However, for me the main reason for choosing jedi over other completion engines was indeed that I get the function stub along with the completion. Do you know what exactly causes this behavior, e.g. are the function stubs not being cached? Are you aware of a workaround?

[davidhalter]

Well, I hope we can make that fast in the future, but that's speaking in about that in like half a year... Basically the whole thing is cached, but I plan to use async stuff to improve this even more. I haven't had a lot of people complaining - you're the first one that complains now. The issues about this are quite dated: davidhalter/jedi#34, #20, #23, #95

Are you working with a slow machine?

[alicee]

Ah, I see. Is that room for improvement in jedi-vim or in the jedi engine itself?

My machine isn't particularly slow, 1.8Ghz i7 and 8GB RAM, and otherwise reasonably responsive.

(Apologies for the duplicate, I was aware of the other tickets but deemed them unrelated as they seemed to mostly reference slow autocompletion upon typing ..)

[davidhalter]

No problem. I wouldn't even classify it as a duplicate anyway. Nobody complained about the lag in insert-mode in quite some time, it could be a different issue. The machine is easily good enough - far better than mine. I thought of something like a Raspberry Pi, which can be a significant performance difference.

Ah, I see. Is that room for improvement in jedi-vim or in the jedi engine itself?

Well since I maintain both it's probably going to be an improvement to Jedi - even if it's something async (which could also be a client improvement), because I like to give every editor the option to do it async without a lot of work. Generally there's hardly any room for improvements in jedi-vim itself, because it's just a few hundred lines of code.

[aaren]

I am also getting slow typing in insert mode. Test case is about 800 lines of code.

Hardware: my desktop is 2*3Ghz Core 2 duo and 4GB RAM, but I'm using network storage on a university network, i.e. my files and python install are on a remote disk (some sort of fast RAID).

If I ssh and work on a machine (32 core, 50GB) that is connected optically to the storage, the problem is possibly diminished slightly - not sure how to accurately profile this though.

On my laptop (2 * 1.9Ghz Core 2 duo, 8GB RAM, SSD), with the same file, I still have the problem.

Setting let g:jedi#show_call_signatures = "0" fixes the problem on all of these machines. This is a shame as I like this feature!

[smeggingsmegger]

Same here. It's unusably slow for me in a 3361 line python file. 2Ghz i7 with 16GB of RAM.

let g:jedi#show_call_signatures = "0" fixes the issue for me.

[fmerges]

Happens to me to. Big python files and when using modules like PyQt

[tobixx]

Can confirm all the above too. Unusable on bigger files.

[M4rtinK]

Seeing the same behavior on a ~1200 line file (part of the Anaconda installer project). The lags can be up to 2-3 seconds long.

[davidhalter]

@M4rtinK Can you tell me where?

[M4rtinK]

It seems to mainly happens when editing the add_argument function calls - for example here. I've been adding help texts to these calls and have seen serious lags when doing this. Also, the function signature being displayed
at the time the lags happen is IMHO wrong:

(args, *kwargs)

So maybe some signature lookup fails, so the value is not cached and the lookup fails over and over again ?

BTW, I'm using vim-jedi at this commit:
c32844d
fix a few jedi-vim tests that have either broken due to the new jedi version or because they were wrong.

And the jedi submodule is at:
7b402d7bbe0e07554f1f97ee3558167961a99b5a
change release to 0.8.0-final0, #395

my Vim version is:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Feb 15 2014 12:09:00)
running on Fedora 20

[edmondburnett]

FWIW, seeing the same behaviour here on Vim 7.4.335 while typing in insert mode. Adding let g:jedi#show_call_signatures = "0" to my .vimrc fixes the issue.

I'm running Archlinux x86_64 with a Intel Q9450 (Core2 Quad 2.66GHz) and 8GB RAM.

[pasky]

Another publicly available file to reproduce this - cma.py of https://pypi.python.org/pypi/cma is an 8k lines of code big and without the workaround above, editing it is nigh impossible on my i3 laptop. Editing whichever place doesn't seem to matter.

I'd be personally happy enough if there was a documented way to imap a shortcut to toggle displaying the call signature at a particular moment; I find it useful, but sometimes it is quite annoying for me in some contexts - in np.array( (even when cached, it stutters) and in print( (tells me nothing new and frequently obscures assignments of whatever variables I want to print).

[tkossak]

I have this problem too - on a file with 10 lines of code.
let g:jedi#show_call_signatures = "0" fixes the problem, but then i lose call signatures :(

[davidhalter]

All right. Could all of you re-test with the current dev branch version of Jedi? I have the feeling that it's so much faster.

@pasky I feel cma is working way faster, now. Before the delay was really a nightmare. Now it's still a bit too slow, but quite OK. Especially when writing code without opening brackets, everything is pretty fast, otherwise you have a "minor" lag. That should eventually be removed by doing the whole thing asynchronous. What do you think?

[aaren]

@davidhalter seems promising so far!

[blueyed]

I think this issue can be closed for now?

Any other opinion?
Is it still slow for anyone?

[pasky]

Sorry for not following up. It's not perfect I guess, but it really is much better than it used to be. Thank you very much! I guess "making the whole thing asynchronous" is really something that needs to wait for neovim now?

I think this is good enough now to warrant closing this.

[blueyed]

Thanks!

[roblevy]

It seems that 0.9.0 (the version currently being got by my pip install --update) still has this problem.

Where should I clone this repository to, to get the latest development version?

[davidhalter]

I think this should actually much better with 0.9.0. If there are still problems, please post (or at least describe your codebase).

[roblevy]

This seems to be enough to trigger the behaviour:

import pandas as pd
import numpy as np

df = pd.DataFrame(np.random.random([3, 6]))
df.head(5).to_latex(header=False, index=True)

When the cursor is inside the parentheses associated with to_latex, the whole thing gets very laggy on my system.

[davidhalter]

yeah. That's kind of related, but it's also a very complex call. Pandas and numpy are huge, so I think this can only be solved by making the whole thing async. If you want to add another issue you can, but it's a different one for me than the other ones here.

[balta2ar]

@davidhalter I already wrote in another issue but it looks like this one is more appropriate.

I wanted to added an important detail: I notice delays when I switch to Insert mode, however that happens not in filetype=python files but in filetype=conf file or when filetype is empty. File size is about 250KB, ~3600 lines.

Is there a way to enable that InsertEnter trigger for python files only? Here is how you can make a file similar to mine:

yes '2013-01-21,14:00,14:39,queue,RT:123456,"comment"' | head -n 5000 > test

I tried to set some delay but there are still lags. Here my configuration:

set noshowmode
let g:jedi#popup_on_dot = 0
let g:jedi#popup_select_first = 0
let g:jedi#use_tabs_not_buffers = 0
let g:jedi#completions_command = ""

let g:jedi#auto_vim_configuration = 0
let g:jedi#auto_initialization = 0
let g:jedi#completions_enabled = 0
let g:jedi#show_call_signatures = "2"

let g:jedi#show_call_signatures_delay = 0

call jedi#configure_call_signatures()

let g:jedi#goto_assignments_command = "<leader>pa"
let g:jedi#goto_definitions_command = "<leader>pd"
let g:jedi#documentation_command = "<leader>pk"
let g:jedi#usages_command = "<leader>pu"
let g:jedi#rename_command = "<leader>pr"

[balta2ar]

Answering my own question, looks like this worked for me:

autocmd FileType python call jedi#configure_call_signatures()

[naggie]

This also worked for me. I am using supertab -- when generating the completion menu it used to pause for seconds at at time.