Comments (22)
Hello, I'm getting this same issue with MacVim (v8.0). I did the same debugging routine and these are the results:
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
1 101.346096 0.000028 tsuquyomi#reloadAndGeterr()
1 101.346040 0.000034 tsuquyomi#geterr()
1 101.346006 0.000185 tsuquyomi#createFixlist()
2 101.343340 0.063150 tsuquyomi#tsClient#sendRequest()
1 101.327256 0.000021 tsuquyomi#tsClient#tsGeterr()
1 101.327235 0.000054 tsuquyomi#tsClient#sendCommandSyncEvents()
2005 101.259433 6.491500 <SNR>39_read_wait()
329564 94.326020 8.146604 <SNR>45_read_pipes()
329564 86.179416 14.344415 <SNR>45_read()
329567 71.835001 4.611500 <SNR>45_vp_pipe_read()
329567 67.223501 2.685630 <SNR>45_libcall_raw_read()
331576 64.900352 22.077475 <SNR>45_libcall()
331576 27.019137 17.488589 <SNR>45_decode_list()
331576 15.803740 8.800073 <SNR>45_encode_list()
663150 9.530548 <SNR>45_decode_size()
990714 7.003667 <SNR>45_encode_size()
2007 0.442174 0.035593 <SNR>39_status()
2007 0.406581 0.044607 <SNR>45_vp_checkpid()
2004 0.019464 tsuquyomi#perfLogger#record()
1 0.018386 0.000154 <SNR>49_flush()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
331576 64.900352 22.077475 <SNR>45_libcall()
331576 27.019137 17.488589 <SNR>45_decode_list()
329564 86.179416 14.344415 <SNR>45_read()
663150 9.530548 <SNR>45_decode_size()
331576 15.803740 8.800073 <SNR>45_encode_list()
329564 94.326020 8.146604 <SNR>45_read_pipes()
990714 7.003667 <SNR>45_encode_size()
2005 101.259433 6.491500 <SNR>39_read_wait()
329567 71.835001 4.611500 <SNR>45_vp_pipe_read()
329567 67.223501 2.685630 <SNR>45_libcall_raw_read()
2 101.343340 0.063150 tsuquyomi#tsClient#sendRequest()
2007 0.406581 0.044607 <SNR>45_vp_checkpid()
2007 0.442174 0.035593 <SNR>39_status()
2004 0.019464 tsuquyomi#perfLogger#record()
18 0.002186 <SNR>19_Highlight_Matching_Pair()
27 0.002214 0.000844 <SNR>52_encode()
3 0.000228 <SNR>40_substitute_last()
1 0.000320 0.000187 tsuquyomi#bufManager#saveTmp()
1 101.346006 0.000185 tsuquyomi#createFixlist()
2 0.000189 0.000184 <SNR>52_decode()
I've completely cleaned out my .vimrc to disable all other plugins and fortunately I have a reliable repro to get it to hang. Also of note I've never used vim-gitgutter
.
from tsuquyomi.
@HerringtonDarkholme yeah I'm using neovim
(version 0.1.3), and you are correct that this seems to be a neovim
-specific issue.
I reinstalled vim-gitgutter
this morning (replacing vim-lazygutter
) and can see that my issue still persists (using neovim
, not vim
). However, vim-gitgutter
makes the issue considerably slower. Without vim-gitgutter
, my TypeScript files still hang, but its variably less common and hangs for a shorter period of time. I don't think vim-gitgutter
is doing anything wrong, but it's clear by the fact that multiple people are having the same issues that something is clashing between tsuquyomi
, neovim
, and vim-gitgutter
.
Chiming in with everyone else, I don't have the time (nor the expertise) to dig through tsuquyomi
, vimproc
, vim-gitgutter
, or neovim
, but I will try and do more benchmarking to at least narrow the scope of where this mysterious hanging issue might be stemming from.
I'll report back when I have done more digging.
from tsuquyomi.
@Quramy I am still having the same issue, only with vim-gitgutter. (I also have vim-fugitive installed, but that doesn't seem to be a problem since I think your commit referenced in this issue solved that problem, thanks!) When I attempt to save a .ts
file with gitgutter
enabled, my whole buffer freezes up for at least a few minutes. My cursor sticks in the vim command line until it unfreezes (or if I kill the process).
To reproduce, make sure you have vim-gitgutter and tsuquyomi installed. Open a .ts
file that is under git source control, make some changes, and try to save the buffer.
I know that it has to be a mismatch between the two of these plugins because it only affects typescript
filetypes. Also, if you run :GitGutterDisable
in the .ts
file before saving, everything works fine and nothing locks up.
from tsuquyomi.
Other times, and I have not quite found a pattern to it yet, :w
will just work, i.e. it won't get stuck. However, it will shrink the editing windows up the top and keeps growing the fugitive status buffer. I think it has to do with the quickfix list popping up. This one is probably even more annoying :)
from tsuquyomi.
Hi, @felixSchl.
I reproduced this. As you said, my plugin attempts to compile buffers created by fugitive :Gvdiff
.
I'll fix it.
from tsuquyomi.
When I run @felixSchl's :20verbose w
command, I get the exact same output:
continuing in BufWritePost Auto commands for "*"
Executing BufWritePost Auto commands for "*.ts"
autocommand silent! call tsuquyomi#reloadAndGeterr()
line 0: silent! call tsuquyomi#reloadAndGeterr()
from tsuquyomi.
I have found a nice way to profile the runtime based on the accepted answer to this SO question: http://stackoverflow.com/questions/12213597/how-to-see-which-plugins-are-making-vim-slow
Here are the function and file runtimes for when I run :GitGutterEnable
and save a .ts
file:
broken-and-slow.log
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
1 100.852586 0.000015 tsuquyomi#reloadAndGeterr()
1 100.852553 0.000135 tsuquyomi#geterr()
1 100.852273 0.000024 tsuquyomi#tsClient#tsGeterr()
1 100.852249 0.000039 tsuquyomi#tsClient#sendCommandSyncEvents()
1 100.851881 0.045618 tsuquyomi#tsClient#sendRequest()
2001 100.795419 38.074341 <SNR>110_read_wait()
3924320 62.370292 51.454817 <SNR>116_read_pipes()
3924320 10.915475 10.380047 <SNR>116_read()
2009 0.827550 0.637654 <SNR>116_libcall()
6 0.535428 0.000078 <SNR>116_vp_pipe_read()
6 0.535351 0.000045 <SNR>116_libcall_raw_read()
2002 0.351010 0.024287 <SNR>110_status()
2002 0.326723 0.034622 <SNR>116_vp_checkpid()
1 0.140389 0.000833 deoplete#init#enable()
1 0.137759 0.000132 remote#define#FunctionBootstrap()
1 0.137563 0.000067 remote#host#Require()
1 0.137497 0.137479 <SNR>71_RequirePythonHost()
2009 0.127477 0.085398 <SNR>116_decode_list()
2009 0.062420 0.045866 <SNR>116_encode_list()
4017 0.042079 <SNR>116_decode_size()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
3924320 62.370292 51.454817 <SNR>116_read_pipes()
2001 100.795419 38.074341 <SNR>110_read_wait()
3924320 10.915475 10.380047 <SNR>116_read()
2009 0.827550 0.637654 <SNR>116_libcall()
1 0.137497 0.137479 <SNR>71_RequirePythonHost()
2009 0.127477 0.085398 <SNR>116_decode_list()
2009 0.062420 0.045866 <SNR>116_encode_list()
1 100.851881 0.045618 tsuquyomi#tsClient#sendRequest()
4017 0.042079 <SNR>116_decode_size()
2002 0.326723 0.034622 <SNR>116_vp_checkpid()
2002 0.351010 0.024287 <SNR>110_status()
2023 0.016553 <SNR>116_encode_size()
2000 0.010159 tsuquyomi#perfLogger#record()
12 0.003794 0.003673 <SNR>63_repo_head_ref()
1 0.001992 0.001954 <SNR>126_JobStart()
1 0.001855 0.001755 gitgutter#diff#run_diff()
1 0.140389 0.000833 deoplete#init#enable()
14 0.000715 0.000672 <SNR>121_encode()
24 0.000606 <SNR>63_repo()
1 0.001119 0.000542 deoplete#init#_variables()
Here are the function and file runtimes for when I run :GitGutterDisable
and save a .ts
file:
working-and-fast.log
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
1 0.286975 0.000016 tsuquyomi#reloadAndGeterr()
1 0.286942 0.000108 tsuquyomi#geterr()
1 0.286645 0.000020 tsuquyomi#tsClient#tsGeterr()
1 0.286624 0.000078 tsuquyomi#tsClient#sendCommandSyncEvents()
1 0.285978 0.000215 tsuquyomi#tsClient#sendRequest()
2 0.285084 0.000179 <SNR>110_read_wait()
10 0.284839 0.283765 <SNR>116_libcall()
4 0.284544 0.000085 <SNR>116_read_pipes()
4 0.284459 0.000199 <SNR>116_read()
6 0.284261 0.000066 <SNR>116_vp_pipe_read()
6 0.284195 0.000037 <SNR>116_libcall_raw_read()
12 0.005583 0.000140 MyFugitive()
12 0.005443 0.000161 fugitive#head()
12 0.004896 0.000437 <SNR>63_repo_head()
12 0.003990 0.003828 <SNR>63_repo_head_ref()
1 0.003144 0.000051 neomake#Make()
1 0.002948 0.000332 <SNR>126_Make()
1 0.002238 0.000267 neomake#MakeJob()
1 0.001959 0.001922 <SNR>126_JobStart()
14 0.001022 0.000951 <SNR>121_encode()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
10 0.284839 0.283765 <SNR>116_libcall()
12 0.003990 0.003828 <SNR>63_repo_head_ref()
1 0.001959 0.001922 <SNR>126_JobStart()
14 0.001022 0.000951 <SNR>121_encode()
24 0.000647 <SNR>63_repo()
1 0.000458 neomake#signs#PlaceVisibleSigns()
10 0.000680 0.000455 <SNR>116_decode_list()
12 0.004896 0.000437 <SNR>63_repo_head()
1 0.002948 0.000332 <SNR>126_Make()
1 0.000316 0.000293 neomake#GetMaker()
1 0.002238 0.000267 neomake#MakeJob()
10 0.000394 0.000243 <SNR>116_encode_list()
19 0.000225 <SNR>116_decode_size()
1 0.285978 0.000215 tsuquyomi#tsClient#sendRequest()
12 0.000208 <SNR>63_sub()
4 0.284459 0.000199 <SNR>116_read()
2 0.285084 0.000179 <SNR>110_read_wait()
24 0.000162 <SNR>63_repo_dir()
12 0.005443 0.000161 fugitive#head()
1 0.000848 0.000160 neomake#MakeHandler()
from tsuquyomi.
You can see that the tsuquyomi
functions are taking a longer total time by a factor of 100. You can also see that functions like <SNR>116_read_pipes()
and <SNR>116_read()
are racking up a self time of ~60 seconds and a count of ~4 million! I'm not even sure what to make of that, but it can't be good. Parsing this is a bit of a mystery to me, but this whole section from the broken-and-slow.log
file is very disconcerting (count, total, and self)
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
1 100.852586 0.000015 tsuquyomi#reloadAndGeterr()
1 100.852553 0.000135 tsuquyomi#geterr()
1 100.852273 0.000024 tsuquyomi#tsClient#tsGeterr()
1 100.852249 0.000039 tsuquyomi#tsClient#sendCommandSyncEvents()
1 100.851881 0.045618 tsuquyomi#tsClient#sendRequest()
2001 100.795419 38.074341 <SNR>110_read_wait()
3924320 62.370292 51.454817 <SNR>116_read_pipes()
3924320 10.915475 10.380047 <SNR>116_read()
from tsuquyomi.
Hmm. So I changed plugins to display signs for git diff in the gutter to a forked project of vim-gitgutter
called vim-lazygutter. It has a few differences but seems quite similar. Surprisingly, it solves the freezing issue on save.
I will use this vim-lazygutter
plugin as a (temporary?) fix for this problem. Now I am unsure if this is even a tsuquyomi
problem or instead a vim-gitgutter
problem. Both plugins are actively updated and changed, so it's hard to find exactly what is causing the freezing.
My guess is that it's still tsuquyomi
seeing as how the original vim-gitgutter
plugin was working fine on save for filetypes that are not typescript
, and the fact that @felixSchl was having similar freezing issues with another diffing plugin (vim-fugitive
).
from tsuquyomi.
Hi @indiesquidge .
I installed vim-gitgutter
and tried to reproduce your issue, but I couldn't...
I use vim-airline
(it's integrated with vim-gitgutter
), the plugin may be related to this issue.
from tsuquyomi.
@Quramy I can't figure out what the exact problem is either, nor am I willing to pour too many more hours into it since vim-lazygutter
is a perfectly suitable substitute for vim-gitgutter
for the functionality I am looking for out of that kind of plugin. If someone else notices an issue like this, perhaps they will be able to shed more light on the matter.
from tsuquyomi.
@indiesquidge Are you using neovim? I think it is a neovim-specific problem....
from tsuquyomi.
Neovim user with vim-gutter. I had the same problem. Changed to vim-lazygutter solved the problem for me.
from tsuquyomi.
Another hit for nvim+gitgutter.
from tsuquyomi.
@faceleg It seems gitgutter uses nvim's async feature and nvim hangs.
from tsuquyomi.
Interesting, I only noticed it when I started using tsuquyomi
from tsuquyomi.
I'm vim-gitgutter's author and I've only just come across this issue. vim-gitgutter uses nvim's async feature; I believe vim-gitgutter uses it correctly but please let me know if you see any improvements I could make.
from tsuquyomi.
@airblade I am not convinced it is vim-gitgutter's fault in this instance, as I've used it for years without issue. This hanging only began when I started using TS and Tsuquyomi.
My gut feeling is that there is somehow an interaction between gitgutter and tsuquyomi, but I have no proof or time to provide any.
from tsuquyomi.
@faceleg I agree. vim-gitgutter doesn't do anything unusual with neovim's async; it uses it as per the documentation. However I don't have time to dig through tsuquyomi or vimproc or neovim either.
from tsuquyomi.
I think this can be closed via airblade/vim-gitgutter@530bf68
from tsuquyomi.
So vim-gitgutter with disabled asynchronous diffs solves the problem?
from tsuquyomi.
@zbindenren Yes
from tsuquyomi.
Related Issues (20)
- Neovim doesn't work without vimproc HOT 1
- Terminal tooltip error
- Show inferred type? HOT 3
- Not an editor command: TsuDefinition HOT 2
- Only enable for *.js files when tsconfig.json present?
- tsuquyomi is not enabled for TS files with JSX in vim 8.2 HOT 4
- No inferred return type `undefined`
- Go to definition not working (<C-]>) on MacVim
- How to browser the completion box using tabs? HOT 1
- A normal quickfix list from :grep, :vimgrep, ... disappear when saving a buffer HOT 2
- Errors ignored on open
- How to remap default binding (Autocompletion)? HOT 1
- Argument of type 'MyType<E>' is not assignable to parameter of type 'Partial<MyType<E>>'
- NCM2 support
- Ctrl-click should also be <C-]> (go to definition)?
- tsuquyomi#hint(): nothing HOT 1
- Slow to open files
- "setlocal completeopt+=menu,preview": from README: not clear what it should do
- ":Unite tsproject": E492: Not an editor command
- E121: Undefined variable: g:tsuquyomi_javascript_support with `syntax on` before `filetype plugin on`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tsuquyomi.