Skip to content
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

Closed
8 of 11 tasks
jacobsandlund opened this issue Mar 28, 2016 · 43 comments
Closed
8 of 11 tasks

Slow vim startup time #2085

jacobsandlund opened this issue Mar 28, 2016 · 43 comments

Comments

@jacobsandlund
Copy link

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:

  • No YCM:  1.5 ms in VimEnter autocommands and   95 ms overall vim start
  • Feb 2013:   17 ms in VimEnter autocommands and 100 ms overall vim start
  • Jan 2014: 148 ms in VimEnter autocommands and 250 ms overall vim start
  • Mar 2016: 550 ms in VimEnter autocommands and 650 ms overall vim start

YCM 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

$ time python -c "import OpenSSL"

real    0m0.052s  (was 0.028 in all subsequent runs)
user    0m0.018s
sys     0m0.022s

Issue Prelude

Please complete these steps and check these boxes (by putting an x inside
the brackets) before filing your issue:

  • I have read and understood YCM's CONTRIBUTING document.
  • I have read and understood YCM's CODE_OF_CONDUCT document.
  • I have read and understood YCM's README, especially the
    Frequently Asked Questions section.
  • I have searched YCM's issue tracker to find issues similar to the one I'm
    about to report and couldn't find an answer to my problem. (Example Google
    search.
    )
  • If filing a bug report, I have included the output of vim --version.
  • If filing a bug report, I have included the output of :YcmDebugInfo.
  • If filing a bug report, I have included the output of
    :YcmToggleLogs stderr.
  • If filing a bug report, I have included which OS (including specific OS
    version) I am using.
  • If filing a bug report, I have included a minimal test case that reproduces
    my issue.
  • I understand this is an open-source project staffed by volunteers and
    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.
  • I understand my issue may be closed if it becomes obvious I didn't
    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.]

@Valloric
Copy link
Member

Valloric commented Apr 2, 2016

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

😞

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?

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.

@Valloric
Copy link
Member

Valloric commented Apr 2, 2016

Looking at the files you posted, here are the YCM parts with the latest March 2016 version:

058.532  000.201  000.201: sourcing /Users/jakesandlund/.vim/bundle/vim-go/plugin/go.vim
059.496  000.867  000.867: sourcing /Users/jakesandlund/.vim/bundle/YouCompleteMe/plugin/youcompleteme.vim
059.946  000.071  000.071: sourcing /Applications/MacVim.app/Contents/Resources/vim/runtime/plugin/getscriptPlugin.vim
...
101.473  013.371  013.371: sourcing /Users/jakesandlund/.vim/bundle/YouCompleteMe/autoload/youcompleteme.vim
650.488  550.384: VimEnter autocommands

It's sourcing autoload/youcompleteme.vim that's slow. 550ms!

Here's what it is on my machine:

175.668  005.862  005.862: sourcing /home/valloric/repos/YouCompleteMe/autoload/youcompleteme.vim
303.843  155.049: VimEnter autocommands

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.

@Valloric
Copy link
Member

Valloric commented Apr 2, 2016

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.

@puremourning
Copy link
Member

For reference, most of the time is in VimEnter which calls youcompleteme#Enable() which calls s:SetUpPython(). The cProfile output for that set of python commands (excluding the future imports, as they have to come first in the code - sigh):

         116452 function calls (113418 primitive calls) in 0.288 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.201    0.201 /Users/ben/.vim/bundle/YouCompleteMe/autoload/../python/ycm/setup.py:44(SetUpYCM)
        5    0.000    0.000    0.126    0.025 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py:473(_eintr_retry_call)
        2    0.000    0.000    0.123    0.061 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py:1379(wait)
        3    0.122    0.041    0.122    0.041 {posix.waitpid}
        1    0.003    0.003    0.104    0.104 /Users/ben/.vim/bundle/YouCompleteMe/autoload/../python/ycm/base.py:18(<module>)
       23    0.004    0.000    0.080    0.003 /Users/ben/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/python-future/src/future/standard_library/__init__.py:441(install_aliases)
        2    0.000    0.000    0.061    0.031 /Users/ben/.vim/bundle/YouCompleteMe/autoload/../python/ycm/paths.py:44(memoizer)
        1    0.000    0.000    0.061    0.061 /Users/ben/.vim/bundle/YouCompleteMe/autoload/../python/ycm/paths.py:53(PathToPythonInterpreter)
        1    0.000    0.000    0.061    0.061 /Users/ben/.vim/bundle/YouCompleteMe/autoload/../python/ycm/paths.py:98(IsPythonVersionCorrect)
        1    0.001    0.001    0.057    0.057 /Users/ben/.vim/bundle/YouCompleteMe/autoload/../python/ycm/youcompleteme.py:18(<module>)
        1    0.000    0.000    0.041    0.041 /Users/ben/.vim/bundle/YouCompleteMe/autoload/../python/ycm/omni_completer.py:18(<module>)
        1    0.001    0.001    0.037    0.037 /Users/ben/.vim/bundle/YouCompleteMe/autoload/../python/ycm/client/base_request.py:18(<module>)

@vheon
Copy link
Contributor

vheon commented Apr 2, 2016

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

@tracyone
Copy link

It slow the gvim startup time in windows 10, it take several seconds i think.I have to lazy load ycm.

@ELD
Copy link

ELD commented Apr 10, 2016

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:

447.347  000.581  000.581: sourcing /Users/eric/.vim/bundle/vim-indent-guides/autoload/color_helper.vim
581.853  131.471  131.471: sourcing /Users/eric/.vim/bundle/YouCompleteMe/autoload/youcompleteme.vim
1078.702  000.184  000.184: sourcing /Users/eric/.vim/bundle/vim-airline/autoload/airline/extensions/tabline/buflist.vim
1079.051  000.069  000.069: sourcing /Users/eric/.vim/bundle/vim-airline/autoload/airline/extensions/tabline/formatters/default.vim
1097.784  000.166  000.166: sourcing /Users/eric/.vim/bundle/vim-signify/autoload/sy.vim
1100.884  002.169  002.169: sourcing /Users/eric/.vim/bundle/tagbar/autoload/tagbar.vim
1118.996  547.367: VimEnter autocommands
1119.007  000.012: before starting main loop
1121.908  002.900: first screen update
1121.912  000.004: --- NVIM STARTED ---

@hdra
Copy link

hdra commented Apr 14, 2016

Mine aren't so bad, maybe SSD have something to do with it?

126.690  000.003: editing files in windows
213.710  083.285  083.285: sourcing /Users/hndr/.vim/bundle/YouCompleteMe/autoload/youcompleteme.vim
397.775  187.800: VimEnter autocommands

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 ycmd server execution flow? Like, is it started when vim is started, or is it started on the first completion request? and is it terminated with vim or is it terminated on every completion request?

@ELD
Copy link

ELD commented Apr 14, 2016

@hdra My 15" rMBP has an SSD as well and I get slow load times on par with the original submitter of this issue.

@krux02
Copy link

krux02 commented Apr 15, 2016

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.

time vim Makefile

real    0m4.634s
user    0m0.756s
sys 0m0.160s

the first I typed in vim was :q, and the limiting factor was not me typing it. It would be nice, if ycm would not block the startup, because this slow startup of 5 seconds makes vim much less attractive as the quick editor to edit one file and quit again.

@hellofwy
Copy link

hellofwy commented Apr 16, 2016

Same problem, with SetUpPython() consuming most of the time. But with python3, the start up time impoved, see below.

Ycm version, 6369046 :
master 6369046 [origin/master] Auto merge of #2099 - micbou:clang-documentation, r=vheon

Vim version: 7.4 patch 1-1743, compilde from source with +python2/dyn and +python3/dyn
System: Debian 8, with system python 2.7.9 and 3.4.2

Install Ycm as the only plugin with Vundle, and run vim by the following command:
vim --cmd 'profile start vim.profile' --cmd 'profile func *' --cmd 'profile file *'

The functions part of the result profile file is:

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
    1   1.135994   0.000408  youcompleteme#Enable()
    1   1.134513             <SNR>20_SetUpPython()
    2   0.004621   0.004030  vundle#config#bundle()
    2   0.000514   0.000143  vundle#config#init_bundle()
    1   0.000510   0.000020  vundle#begin()
    1   0.000490   0.000107  vundle#rc()
    1   0.000347   0.000042  <SNR>20_SetUpCpoptions()
    1   0.000305             <SNR>20_Pyeval()
    1   0.000220             youcompleteme#EnableCursorMovedAutocommands()
    1   0.000200             <SNR>20_SetUpKeyMappings()
    1   0.000197   0.000015  vundle#end()
    2   0.000192             <SNR>4_parse_name()
    1   0.000182   0.000022  vundle#config#activate_bundles()
    2   0.000165   0.000105  <SNR>4_rtpath()
    1   0.000152             <SNR>12_Highlight_Matching_Pair()
    1   0.000151             <SNR>20_OnVimLeave()
    1   0.000095             <SNR>4_rtp_add_a()
    1   0.000088   0.000044  <SNR>13_VimEnter()
    2   0.000088             <SNR>13_LocalBrowse()
    1   0.000080   0.000034  vundle#config#init()

When using system python3, the startup time improved.
By adding the following in line before Vundle configurations in .vimrc to use the system python3:
call has('python3')
The result:

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
    1   0.319594   0.000562  youcompleteme#Enable()
    1   0.317966             <SNR>74_SetUpPython()
    3   0.083444   0.000086  <SNR>39_on_window_changed()
    3   0.059879   0.000468  <SNR>39_init()
    1   0.048623   0.000050  airline#switch_theme()
    3   0.040861   0.000435  airline#extensions#tagbar#currenttag()
  103   0.039909   0.023809  airline#highlighter#exec()
    1   0.039634   0.000079  airline#load_theme()
    3   0.038993   0.003805  airline#highlighter#highlight()
    2   0.034060   0.000400  tagbar#currenttag()
    2   0.033642   0.000319  <SNR>75_Init()
    4   0.031062   0.000581  airline#update_statusline()
    4   0.030454   0.000417  <SNR>40_invoke_funcrefs()
    1   0.030442   0.000039  airline#highlighter#load_theme()
    2   0.024261   0.000670  <SNR>75_ExecuteCtags()
    4   0.023435   0.002647  272()
    1   0.021872   0.000887  nerdtree#postSourceActions()
  203   0.020323   0.006478  airline#highlighter#get_highlight()
    1   0.020175   0.000423  nerdtree#ui_glue#createDefaultBindings()
   50   0.019727   0.000239  NERDTreeAddKeyMap()

@puremourning
Copy link
Member

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.

@vheon
Copy link
Contributor

vheon commented Apr 24, 2016

@puremourning I was thinking that as well. I was also thinking about leverage the new job api if available.

@Valloric
Copy link
Member

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.

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.

@micbou
Copy link
Collaborator

micbou commented Apr 25, 2016

The check would still be in YCM but instead of doing it in SetUpYCM, we would do it in _NotifyUserIfServerCrashed.

@Valloric
Copy link
Member

I'd be fine with that.

@micbou
Copy link
Collaborator

micbou commented Apr 26, 2016

Ok, I'll work on it.

homu added a commit to ycm-core/ycmd that referenced this issue May 2, 2016
[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 -->
@snorez
Copy link

snorez commented Jun 18, 2016

@hellofwy use python3 works,
python2 startuptime

FUNCTION  youcompleteme#Enable()
Called 1 time
Total time:   1.582035
 Self time:   0.016691

count  total (s)   self (s)
    1   0.000041   0.000022   call s:SetUpBackwardsCompatibility()

                              " This can be 0 if YCM libs are old or -1 if an exception occured while
                              " executing the function.
    1   1.564470   0.000014   if s:SetUpPython() != 1
                                return
                              endif

    1   0.000101   0.000029   call s:SetUpCommands()
    1   0.000246   0.000008   call s:SetUpCpoptions()
    1   0.000027   0.000009   call s:SetUpCompleteopt()
    1   0.000168   0.000007   call s:SetUpKeyMappings()

    1              0.000002   if g:ycm_show_diagnostics_ui
                                call s:TurnOffSyntasticForCFamily()
                              endif

    1   0.000078   0.000008   call s:SetUpSigns()
    1   0.016337   0.016281   call s:SetUpSyntaxHighlighting()

python3 startuptime

FUNCTION  youcompleteme#Enable()
Called 1 time
Total time:   0.471536
 Self time:   0.014251

count  total (s)   self (s)
    1   0.001259   0.001237   call s:SetUpBackwardsCompatibility()

                              " This can be 0 if YCM libs are old or -1 if an exception occured while
                              " executing the function.
    1   0.456367   0.000019   if s:SetUpPython() != 1
                                return
                              endif

    1   0.000111   0.000030   call s:SetUpCommands()
    1   0.000182   0.000010   call s:SetUpCpoptions()
    1   0.000043   0.000015   call s:SetUpCompleteopt()
    1   0.000193   0.000012   call s:SetUpKeyMappings()

    1              0.000001   if g:ycm_show_diagnostics_ui
                                call s:TurnOffSyntasticForCFamily()
                              endif

    1   0.000080   0.000008   call s:SetUpSigns()
    1   0.012567   0.012503   call s:SetUpSyntaxHighlighting()

@naseer
Copy link

naseer commented Oct 13, 2016

I'm seeing this with vim 8.0 compiled with python3

239.756 073.889: opening buffers
239.812 000.056: BufEnter autocommands
239.814 000.002: editing files in windows
243.714 001.720 001.720: sourcing /usr2/naseer/dotfiles/vim/plugged/YouCompleteMe/autoload/youcompleteme.vim
1008.404 767.870: VimEnter autocommands
1008.412 000.008: before starting main loop
1015.896 007.484: first screen update
1015.900 000.004: --- VIM STARTED ---

@carlpaten
Copy link

Vim 7.4 +python3, Python 3.5.2:

276.121  063.545: opening buffers
276.987  000.866: BufEnter autocommands
277.053  000.066: editing files in windows
291.815  002.810  002.810: sourcing /home/carl/.vim/bundle/YouCompleteMe/autoload/youcompleteme.vim
734.544  455.681: VimEnter autocommands
734.550  000.006: before starting main loop
763.700  029.150: first screen update
763.702  000.002: --- VIM STARTED ---

@naseer
Copy link

naseer commented Dec 6, 2016

neovim starts up much faster though

@k4rtik
Copy link

k4rtik commented Dec 6, 2016

@naseer still not fast enough, as compared to turning off YCM.

@puremourning
Copy link
Member

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.

@bstaletic
Copy link
Collaborator

@puremourning

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.

@puremourning
Copy link
Member

@bstaletic thanks. At least the first thing you noticed was that it started, rather than crashed. That's a relief :)

@bstaletic
Copy link
Collaborator

@puremourning
I have preliminary results. I won't be commenting on its stability as I haven't been testing enough. For now I have no issues at all.

Your fork with cache being dropped: 3127ms
Oblitum's fork with cache being dropped: 7212ms +- 1000ms

Your fork without cache being dropped: 100ms
Oblitum's fork without cache being dropped: 235ms

How I measured: vim src/main.c --startuptime test

Interesting part of test file:

2604.637  024.302  024.302: sourcing /home/bstaletic/.vim/pack/bundle/opt/YouCompleteMe/autoload/youcompleteme.vim
5731.002  3190.973: VimEnter autocommands
--
2418.049  003.416  003.416: sourcing /home/bstaletic/.vim/pack/bundle/opt/YouCompleteMe/autoload/youcompleteme.vim
9630.426  333.311  333.311: sourcing /home/bstaletic/.vim/pack/bundle/start/ultisnips/autoload/UltiSnips.vim
--
194.709  001.452  001.452: sourcing /home/bstaletic/.vim/pack/bundle/opt/YouCompleteMe/autoload/youcompleteme.vim
295.667  105.525: VimEnter autocommands
--
190.900  001.195  001.195: sourcing /home/bstaletic/.vim/pack/bundle/opt/YouCompleteMe/autoload/youcompleteme.vim
425.577  016.139  016.139: sourcing /home/bstaletic/.vim/pack/bundle/start/ultisnips/autoload/UltiSnips.vim

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?

anurag90x pushed a commit to anurag90x/vim-dotfiles that referenced this issue Jan 3, 2017
homu added a commit that referenced this issue Jan 26, 2017
[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 -->
@ghost
Copy link

ghost commented Mar 2, 2017

@puremourning is there a reason why your fast-start branch is not merged yet?

@puremourning
Copy link
Member

There are many reasons:) not least time, effort and complexity

@kylemacfarlane
Copy link

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?

@kylemacfarlane
Copy link

Some other interesting things about Windows vs WSL (done with identical .vimrcs of course):

  • Overall, time to "--- VIM STARTED ---" is 0-60ms faster under WSL than regular Windows.
  • This difference comes from the fact that almost every plugin seems to be 10-20ms faster under WSL
  • The only exception is YCM which is 2-3x slower
  • Even though start up times are almost identical, Vim feels like it takes a lot longer to start under WSL. I guess the Windows GUI is just faster at drawing the window.

@kylemacfarlane
Copy link

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.

@ajorgensen
Copy link

I can confirm that re-installing vim with python3 support reduced the startup time of youcompleteme by 50% on OSX 10.12.3

@vheon
Copy link
Contributor

vheon commented Mar 10, 2017

@ajorgensen consider that if you pulled the latest master, with commit 09a08d3 we've improved startup time even further.

@ajorgensen
Copy link

Awesome! Looks like i saw an additional 25% increase using that commit.

@micbou
Copy link
Collaborator

micbou commented Mar 27, 2017

PRs #2517, #2563, #2575, and #2585 significantly improved startup time. YCM should now take about 100ms to start (on recent machines). I feel this is good enough and thus I am closing the issue. If you think this should be further improved, we can always reopen.

@micbou micbou closed this as completed Mar 27, 2017
@sheerun
Copy link

sheerun commented Nov 19, 2017

@micbou Would it be possible to make these 100ms asynchronous on Vim 8 or neovim?

@nodingneu
Copy link

With YouCompleteMe I consistently get 100 to 200 ms, without it I consistently get less than 1 millisecond.

Please can you reduce it further.

@bstaletic
Copy link
Collaborator

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 python-future, but that will have to wait the end of life of python2.

@bstaletic
Copy link
Collaborator

However, this seems to improve things as far as measuring with --startuptime goes:

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 --- VIM STARTED --- before time runs out. A similar effect can be achieved if a user sets up YCM to be loaded on something like CursorHold.

@Shougo
Copy link

Shougo commented Nov 28, 2018

@theonlygusti I think the slowness is Python loading time.
It takes almost 200ms. If you don't want to loading Python, you should not load YouCompleteMe on statup.

@ysmolski
Copy link

This is showstopper for me still. On my machine using YCM means +170ms startup delay:

130.665  000.909  000.909: sourcing /Users/thorn/.vim/bundle/YouCompleteMe/autoload/youcompleteme.vim
130.985  000.029  000.029: sourcing /opt/local/share/nvim/runtime/autoload/provider.vim
304.827  174.288: VimEnter autocommands
304.836  000.009: UIEnter autocommands

from neovim/neovim#5728 (comment)

Please look at this issue.

@bstaletic
Copy link
Collaborator

Vim needs to load libpython.so, which takes about 100ms. YCM in vim starts in about 110ms. That means that the entire work that YCM needs to do is ~10ms. Where neovim is spending the other ~160ms, I have no clue.

@puremourning
Copy link
Member

Neovim python approach is notoriously slow.

@ycm-core ycm-core locked and limited conversation to collaborators Jun 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests