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
Slow vim startup time #2085
Comments
😞
We've added a massive amount of stuff in the last several years; kinda hard to sum it up. We haven't noticed a slowdown in startup time, at least I haven't. But the data you present is compelling and disheartening. @puremourning @micbou @vheon We should probably take a look at startup time. I don't think we've ever put much effort into optimizing it, so there should be some low-hanging fruit. I also have a gut feeling that a Vim with Python 3.5 (plus ycmd running in Python 3.5) should do substantially better. |
Looking at the files you posted, here are the YCM parts with the latest March 2016 version:
It's sourcing Here's what it is on my machine:
About ~220ms. Better, but not good. I also have a pretty beefy machine at home and I run Ubuntu, so the numbers aren't really comparable. In general I start one vim instance and keep it around for the whole day, so I don't notice startup time much. #2071 might also be related. |
I think we may want to add a benchmark test for startup time to Travis so that this doesn't regress after we improve it. |
For reference, most of the time is in
|
@puremourning so the majority of the time we're waiting on some process to start it seems :/ could we do it in a separate thread? |
It slow the gvim startup time in windows 10, it take several seconds i think.I have to lazy load ycm. |
Can confirm. Under NeoVim (and Vim) on Mac OS X 10.11.5 beta, there's almost 500ms of startup time devoted to sourcing YCM. Relevant portions:
|
Mine aren't so bad, maybe SSD have something to do with it?
But I did notice a slight slowdown after I updated YCM to the latest earlier this morning. I also have been noticing a lot more "Connection timed out" issue. On a (maybe) related note, can anyone explain to me the |
@hdra My 15" rMBP has an SSD as well and I get slow load times on par with the original submitter of this issue. |
I would like to add my two cents here. I am on a computer where my home is mounted as a network filesystem, so startup is much slower.
the first I typed in vim was |
Same problem, with SetUpPython() consuming most of the time. But with python3, the start up time impoved, see below. Ycm version, 6369046 : Vim version: Install Ycm as the only plugin with Vundle, and run vim by the following command: The functions part of the result profile file is:
When using system python3, the startup time improved.
|
One thing that might speed things up is to avoid spawning a whole new python process to check the core version. That check is actually also performed by ycmd when it starts up, so we could revert to just handling the fact that ycmd failed to start (and returned exit code of 2) for showing the "you need to recompile" warning. |
@puremourning I was thinking that as well. I was also thinking about leverage the new |
Eh, not a big fan of this idea. AFAIR we started with that and then added the check in YCM because the behavior was confusing without it. |
The check would still be in YCM but instead of doing it in |
I'd be fine with that. |
Ok, I'll work on it. |
[READY] Add checks to ycm_core library when starting ycmd Do the following checks on the ycm_core library when starting ycmd: - missing library; - compiled with Python 2 but imported with Python 3; - compiled with Python 3 but imported with Python 2; - outdated library. When one of these errors is encountered, exit with a non-zero status code specific to the error. These status codes will be used in the YCM client to display an appropriate error message to the user. In addition, starting a separate process to check the core version will not be needed anymore. This should slighty improve the Vim startup time. See issue ycm-core/YouCompleteMe#2085. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/ycmd/467) <!-- Reviewable:end -->
@hellofwy use python3 works,
python3 startuptime
|
I'm seeing this with vim 8.0 compiled with python3 239.756 073.889: opening buffers |
Vim 7.4 +python3, Python 3.5.2:
|
neovim starts up much faster though |
@naseer still not fast enough, as compared to turning off YCM. |
Anyone having particular problems, please try this branch: https://github.com/puremourning/YouCompleteMe/tree/fast-start It is a set of highly experimental, not fully tested changes that reduce YCM's impact on startup time from ~500ms to ~150ms. |
I'm testing your branch right now. The first thing I noticed is the faster start. I'll give it as much testing as possible, but I've grown quite used to oblitum's fork and its parameter hinting and I'm in the middle of some project, so my testing of your branch might not be quite adequate. Either way, I'll report back my experience with these changes. |
@bstaletic thanks. At least the first thing you noticed was that it started, rather than crashed. That's a relief :) |
@puremourning Your fork with cache being dropped: 3127ms Your fork without cache being dropped: 100ms How I measured: Interesting part of
The non-cached bechmarks are accurate. It really does take my laptop seconds to start YCM the first time as I have a pretty slow HDD. I'm not sure if ~250ms of cached start of Oblitum fork shows the real state of things. If I remember correctly, it usually does take it ~500ms, but I can't reproduce that result right now. One more thing. Is this the right place to post my results? Or should I report my findings in a different way? |
This is till ycm-core/YouCompleteMe#2085 is resolved.
[READY] Rely on connect timeout instead of checking that the server is alive Currently, we always check that the ycmd process is up (with the `IsServerAlive` method) before sending a request. Without this check, each request could block Vim until a `NewConnectionError` exception is raised if the server crashed. This is the case on Windows where it takes ~1s before the exception is raised which makes Vim unusable. However, even with this check, Vim may still be blocked in the following cases: - the server crashes just after the check but before sending the request; - the server is up but unresponsive (e.g. its port is closed). To avoid both cases, we instead use [the connect timeout parameter from Requests](http://docs.python-requests.org/en/master/user/advanced/?highlight=connect%20timeout#timeouts) and set it to a duration sufficiently short (10 ms) that the blocking can't be noticed by the user. Since the server is supposed to run locally (this is what YCM is designed for), 10ms is largely enough to establish a connection. The `IsServerAlive` check is removed almost everywhere except in `OnFileReadyToParse` because we still want to notify the user if the server crashed. This change makes it possible to not have to [wait for the server to be healthy before sending asynchronous requests](https://github.com/Valloric/YouCompleteMe/blob/master/python/ycm/client/base_request.py#L137-L138). This will dramatically improve startup time (see issue #2085) and fixes #2071. Next PR once this one is merged. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2514) <!-- Reviewable:end -->
@puremourning is there a reason why your fast-start branch is not merged yet? |
There are many reasons:) not least time, effort and complexity |
I'm using the same .vimrc on Windows and WSL (the newish Linux subsystem on Windows). The .vimrcs are symlinked but each version has its own .vim folder. I find that YCM on Windows takes 150ms but on WSL I'm seeing 500ms like others in this thread. All I'm interested in is Python and node/tern so on Windows that's all I have installed. My guess is that other tools are installed by default on Ubuntu and YCM is checking them even though I don't use them. So my question is, what could those tools be? |
Some other interesting things about Windows vs WSL (done with identical .vimrcs of course):
|
Turns out that the problem was Vim under WSL had fallen back to Python 2. Making sure it was using Python 3 reduced start up times to 150ms. |
I can confirm that re-installing vim with python3 support reduced the startup time of youcompleteme by 50% on OSX 10.12.3 |
@ajorgensen consider that if you pulled the latest master, with commit 09a08d3 we've improved startup time even further. |
Awesome! Looks like i saw an additional 25% increase using that commit. |
@micbou Would it be possible to make these 100ms asynchronous on Vim 8 or neovim? |
With YouCompleteMe I consistently get 100 to 200 ms, without it I consistently get less than 1 millisecond. Please can you reduce it further. |
Once upon a time, I played with making the start up async and I have failed. Other than that, further reduction in start up speed can only be made with smaller number of dependencies and the only dependency I can see being dropped is |
However, this seems to improve things as far as measuring with diff --git a/plugin/youcompleteme.vim b/plugin/youcompleteme.vim
index 3cc57480..908eaaf9 100644
--- a/plugin/youcompleteme.vim
+++ b/plugin/youcompleteme.vim
@@ -274,7 +274,7 @@ if has( 'vim_starting' ) " Loading at startup.
" https://github.com/Valloric/YouCompleteMe/pull/2473#issuecomment-267716136
augroup youcompletemeStart
autocmd!
- autocmd VimEnter * call youcompleteme#Enable()
+ autocmd VimEnter * call timer_start( 100, {id->execute('call youcompleteme#Enable()')} )
augroup END
else " Manual loading with :packadd.
call youcompleteme#Enable() Thechnically, this just delays starting up YCM, in hopes that vim will have time to get to |
@theonlygusti I think the slowness is Python loading time. |
This is showstopper for me still. On my machine using YCM means +170ms startup delay:
from neovim/neovim#5728 (comment) Please look at this issue. |
Vim needs to load |
Neovim python approach is notoriously slow. |
Hello! Yesterday I upgraded YCM (after a fresh install of the OS) and found that vim started slowly. I see that slow startup times has been brought up before: #893, #1343, and #1386.
I've been happily using YCM with few issues for almost three years (seriously, great plugin!), and I've never experienced slow startup times. After some digging, I think I know why: the version I was using was over two years old. Newer versions are slower.
In this gist I have the output of
vim --startuptime
for three versions of YCM (and one test without): one from February 2013 (2897d56: after this blog post), one in January 2014 (91368c0: roughly the version I had been using until yesterday), and one from yesterday (1b76af4).Here are the results:
1.5 ms
inVimEnter autocommands
and95 ms
overall vim start17 ms
inVimEnter autocommands
and100 ms
overall vim start148 ms
inVimEnter autocommands
and250 ms
overall vim start550 ms
inVimEnter autocommands
and650 ms
overall vim startYCM takes 4 times longer to start than it did two years ago, and 30 times longer than when it was announced. That's pretty concerning. Yet, I see the response to this issue has been that there is nothing that can be done.
What has changed in the past few years that makes YCM start slower? Is it more functionality and therefore more code that needs to load? Is it newer versions of dependencies that are slower? Can any of this functionality be lazily loaded, instead of taking time up front?
For now I will use an older version of YCM without the startup delay, but I hope that this issue can be resolved so I can get any bug fixes or compelling new features that have been developed in the past few years. Thanks!
Computer tech specs:
OS X El Capitan Version 10.11.4
MacBook Pro (Retina, 13-inch, Late 2013)
2.4 GHz Intel Core i5
8 GB 1600 MHz DDR3
251 GB Flash Storage
Vim Version: https://gist.github.com/jakesandlund/c0a569b0e9126c30ad62
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 26 2016 06:40:26)
MacOS X (unix) version
Included patches: 1-1655
Compiled by travis@Traviss-Mac-139.local
Issue Prelude
Please complete these steps and check these boxes (by putting an
x
insidethe brackets) before filing your issue:
Frequently Asked Questions section.
about to report and couldn't find an answer to my problem. (Example Google
search.)
vim --version
.:YcmDebugInfo
.:YcmToggleLogs stderr
.version) I am using.
my issue.
that any help I receive is a selfless, heartfelt gift of their free time. I
know I am not entitled to anything and will be polite and courteous.
actually perform all of these steps.
Thank you for adhering to this process! It ensures your issue is resolved
quickly and that neither your nor our time is needlessly wasted.
Issue Details
[If filing a bug report, please include a list of steps that describe how to
reproduce the bug you are experiencing. Also include test code if relevant.]
The text was updated successfully, but these errors were encountered: