Gvim taking a minute or more to start

[A. S. Budden]

Hi

On my work PCs, gvim seems to take an incredibly long time to start up, sometimes as much as 90 seconds.  At the moment I work round it by starting a session at the start of the day and then just reusing the same session as much as possible, but I'd really like to fix it.

I'm pretty sure it's something about my configuration / plugins / something (gvim -u NONE -U NONE takes about 5 seconds), but I'm really struggling to diagnose the issue / work out which plugin is responsible.  I've got a lot of plugins that I've added over the years and I probably don't need all of them, but it would be nice to which is the culprit rather than just start culling them at random.

I've attached three startuptime logs, all created one-after-the-other with "gvim --startuptime timecostN.txt timecostN.txt".  As you can see in these, the delay seems to happen at different times in each log.

In timecost1.txt, we have:

4579.000  030.000  030.000: sourcing $VIM\_gvimrc
42416.000  37840.000: starting GUI

In timecost2.txt, we have:

026.000  001.000: init highlight
32606.000  000.000  000.000: sourcing C:\vim\runtime\ftoff.vim

and:

38738.000  000.000  000.000: sourcing C:\vim\runtime\ftplugin\text.vim
88937.000  047.000  047.000: sourcing C:\vim\vimfiles\bundle\TagHighlight\autoload\TagHighlight\ReadTypes.vim

In timecost3.txt, we have:

8484.000  000.000  000.000: sourcing C:\vim\runtime\ftplugin\text.vim
20153.000  034.000  034.000: sourcing C:\vim\vimfiles\bundle\TagHighlight\autoload\TagHighlight\ReadTypes.vim
45722.000  000.000  000.000: sourcing C:\vim\vimfiles\bundle\TagHighlight\autoload\TagHighlight\Debug.vim

Obviously, two out of three of those logs had TagHighlight in the time-consuming bit, but I've tried removing that plugin and it made no difference at all.

These logs were all made with gvim 8.2.4072, downloaded from tuxproject.de and running on Windows 10 Professional.  I also tested with gvim 9 downloaded from www.vim.org and the results were the same.  On my other work PC I have gvim 9 downloaded from tuxproject.de and it takes a similar amount of time to start-up, although I haven't used the --startuptime logger.

Can anyone suggest what I can do to try to diagnose the cause of the delay?  The only thought I've had is to delete plugins from the bundle directory one-by-one until it starts quickly but that seems a rather haphazard approach.

Thanks in advance for any help you can offer

Al

--

http://www.cgtk.co.uk

[David Lowry-Duda]

>I'm pretty sure it's something about my configuration / plugins /
>something (gvim -u NONE -U NONE takes about 5 seconds), but I'm really
>struggling to diagnose the issue / work out which plugin is
>responsible. I've got a lot of plugins that I've added over the years
>and I probably don't need all of them, but it would be nice to which is
>the culprit rather than just start culling them at random.

Five seconds feels like a *really* long time for base gvim. I don't use
Windows, so perhaps my scale is off. But this feels like an eternity.

On my work machine, gvim with -u NONE takes 100 milliseconds to start.
It takes 600 milliseconds to start with my current vimrc. I use several,
but perhaps not a very large amount, of plugins. I interpret this to
mean that it might be reasonable for startuptime to multiply by a factor
of 6 or so when loading several plugins?

>Can anyone suggest what I can do to try to diagnose the cause of the
>delay? The only thought I've had is to delete plugins from the bundle
>directory one-by-one until it starts quickly but that seems a rather
>haphazard approach.

I'll note that a binary search for relevant plugins is probably faster
than a one-by-one search. I'm sorry I wasn't more helpful.

- DLD

[Kennedy, Marcus A.]

From: vim...@googlegroups.com <vim...@googlegroups.com> On Behalf Of A. S. Budden
Sent: Thursday, September 8, 2022 9:44 AM

> On my work PCs, gvim seems to take an incredibly long time to start up, sometimes as much as 90 seconds.

 

Is this a PC that is attached to a network that has IT governing HOMEDRIVE?

 

> In timecost1.txt, we have:

 

4579.000  030.000  030.000: sourcing $VIM\_gvimrc
42416.000  37840.000: starting GUI

 

Reason being, 5 seconds was to open $VIM\_gvimrc (which, on my computer is %HOMEDRIVE%\_vimrc).  If you have latency when accessing %HOMEDRIVE% perhaps that is your issue?

 

I had a similar issue and remapped my %HOMEDRIVE% (in Windows 10) to a local directory by creating a shortcut within Startup with:

 

C:\Windows\System32\subst.exe P: "A:\home"

 

My vim now starts up nicely -- though, I no longer have a network attached HOMEDRIVE.

 

0.02USD,

Andy

 

[A. S. Budden]

On Thu, 8 Sept 2022 at 17:33, David Lowry-Duda <da...@lowryduda.com> wrote:

>I'm pretty sure it's something about my configuration / plugins /
>something (gvim -u NONE -U NONE takes about 5 seconds), but I'm really
>struggling to diagnose the issue / work out which plugin is
>responsible.  I've got a lot of plugins that I've added over the years
>and I probably don't need all of them, but it would be nice to which is
>the culprit rather than just start culling them at random.

Five seconds feels like a *really* long time for base gvim. I don't use
Windows, so perhaps my scale is off. But this feels like an eternity.

Yes, it isn't ideal, but I'd take 5 seconds over 30+ any day!

 

On my work machine, gvim with -u NONE takes 100 milliseconds to start.
It takes 600 milliseconds to start with my current vimrc. I use several,
but perhaps not a very large amount, of plugins. I interpret this to
mean that it might be reasonable for startuptime to multiply by a factor
of 6 or so when loading several plugins?

>Can anyone suggest what I can do to try to diagnose the cause of the
>delay?  The only thought I've had is to delete plugins from the bundle
>directory one-by-one until it starts quickly but that seems a rather
>haphazard approach.

I'll note that a binary search for relevant plugins is probably faster
than a one-by-one search. I'm sorry I wasn't more helpful.

That's a good point - I'll try that when I'm back at work tomorrow.

Al

[A. S. Budden]

On Thu, 8 Sept 2022 at 17:51, Kennedy, Marcus A. <Marcus....@rocket.com> wrote:

From: vim...@googlegroups.com <vim...@googlegroups.com> On Behalf Of A. S. Budden
Sent: Thursday, September 8, 2022 9:44 AM

> On my work PCs, gvim seems to take an incredibly long time to start up, sometimes as much as 90 seconds.

 

Is this a PC that is attached to a network that has IT governing HOMEDRIVE?

It is on a PC, but IT aren't controlling the $VIM directory

 

 

> In timecost1.txt, we have:

 

4579.000  030.000  030.000: sourcing $VIM\_gvimrc
42416.000  37840.000: starting GUI

 

Reason being, 5 seconds was to open $VIM\_gvimrc (which, on my computer is %HOMEDRIVE%\_vimrc).  If you have latency when accessing %HOMEDRIVE% perhaps that is your issue?

$VIM is c:\vim.  I have the vim binaries installed in c:\vim; the runtime files are in c:\vim\runtime and my configuration is in c:\vim\vimfiles.  c:\vim\_vimrc and c:\vim\_gvimrc each have one line in them: `runtime vimrc` / `runtime gvimrc`, which causes vim to read the vimrc/gvimrc file in c:\vim\vimfiles.  The folder c:\vim\vimfiles is under (mercurial) version control, hence wanting the configuration files in there rather than in the folder above.

 

The C: drive is a local SSD, so it seems unlikely that it would be the cause of the delay (although who knows what extra slow-downs the IT department have introduced!)

Al

[Gary Johnson]

On 2022-09-08, David Lowry-Duda wrote:
> >I'm pretty sure it's something about my configuration / plugins /
> >something (gvim -u NONE -U NONE takes about 5 seconds), but I'm
> >really struggling to diagnose the issue / work out which plugin is
> >responsible. I've got a lot of plugins that I've added over the
> >years and I probably don't need all of them, but it would be nice
> >to which is the culprit rather than just start culling them at
> >random.
>
> Five seconds feels like a *really* long time for base gvim. I don't
> use Windows, so perhaps my scale is off. But this feels like an
> eternity.

If it takes 5 seconds to start gvim with no plugins, especially when
using a local SSD, something is very wrong someplace. I just ran
this command on my Windows 10 PC (with a hard drive) from a Cygwin
prompt so that I could measure the time:

$ time /cygdrive/c/Program\ Files/Vim/vim90/gvim -f -c scriptnames -cq

real 0m0.216s
user 0m0.000s
sys 0m0.000s

I had it execute :scriptnames just so it would have something
to do before immediately quitting. And that's with loading all
my plugins. With "-N -u NONE -i NONE", the real time dropped
to 0.17 s.

I suspect that whatever is causing that 5-second startup time is
contributing to the read times of every file that gvim opens.
So, while 5 seconds is better than 30, solving that 5-second issue
may solve the rest.

Unfortunately, I don't anything about diagnosing issues with Windows
or security programs.

Regards,
Gary

[Tim Chase]

On 2022-09-08 11:30, Gary Johnson wrote:
> I suspect that whatever is causing that 5-second startup time is
> contributing to the read times of every file that gvim opens.
> So, while 5 seconds is better than 30, solving that 5-second issue
> may solve the rest.
>
> Unfortunately, I don't anything about diagnosing issues with Windows
> or security programs.

While my Windows experience is similarly limited, the symptoms sound
suspiciously like either anti-virus software or a virus intervening
on every file-system read to see if the file is infected/valuable.

I'd be curious if apps take a similar amount of "bonus" time to
load. If you (OP) have Python installed on the machine, it would
be interesting to run the python interpreter and issue

C:\> python -q
>>> import os
>>> f = open(os.path.expanduser("~/_vimrc"))
>>> f.close()

Entering that `open()` call should take negligible time, the blink
of an eye. If that takes any noticeable amount of time, something
outside vim is intercepting all your (OP's) file-reads at an
atrocious cost.

-tim

[A. S. Budden]

That specific command produced an immediate file-not-found message (the only _vimrc I have is in c:/vim). Running:

>>> f = open('c:/vim/_vimrc')

>>> f2 = open('c:/vim/vimfiles/vimrc')

both commands were instantaneous

[A. S. Budden]

Okay, now that's REALLY weird.

Scriptnames slows things down a little as I have to scroll through a page or two, but if I open a Cygwin64 Terminal and run:

time /cygdrive/c/vim/gvim.exe -f -c "echo h" -cq

The result is 866 ms. Adding -u NONE -U NONE changes it to 197 ms.

Removing all the arguments results in a near-instantaneous gvim window popping up!

So if I run Windows gvim from a cygwin terminal it starts quickly but if I run it from a windows command prompt or from windows explorer, it takes ages. I've tried this lots of times & it seems to be repeatable (I even created 10 instances of gvim in a loop and they all appeared straightaway).

I tried removing the HOME environment variable from cygwin (it's not set to anything in the Windows system, whereas it's set to /home/al in cygwin) and ran the command again from the cygwin terminal and it took a long time to start. I reset HOME to /home/al and it still took a long time to start! Opening a new cygwin terminal resulted in a quick start again. This is really weird!

In /home/al there's a .vimrc that contains:

let &rtp ='/cygdrive/c/vim/vimfiles,'.&rtp

runtime! vimrc

Removing /home/al/.vimrc seems to make no difference to the results.

I think I'm even more confused now!

I should probably note that this is on a different work PC to the one I was using for tests yesterday, but I have 3 PCs that all show the slow start-up problem.

Al

[A. S. Budden]

On Fri, 9 Sept 2022 at 12:06, A. S. Budden <abu...@gmail.com> wrote:

On Thu, 8 Sept 2022, 19:29 Gary Johnson, <gary...@spocom.com> wrote:

On 2022-09-08, David Lowry-Duda wrote:So if I run Windows gvim from a cygwin terminal it starts quickly but if I run it from a windows command prompt or from windows explorer, it takes ages. I've tried this lots of times & it seems to be repeatable (I even created 10 instances of gvim in a loop and they all appeared straightaway).

I tried removing the HOME environment variable from cygwin (it's not set to anything in the Windows system, whereas it's set to /home/al in cygwin) and ran the command again from the cygwin terminal and it took a long time to start. I reset HOME to /home/al and it still took a long time to start! Opening a new cygwin terminal resulted in a quick start again. This is really weird!

I repeated this test on the other work PC and got exactly the same results.   I also tested it on my home PC and, while the startup time is much faster from the command prompt than on my work PCs, even on the home PC gvim starts quicker from a cygwin prompt than from a Windows command prompt.

Al

[jr]

hi,

On Fri, 9 Sept 2022 at 12:39, A. S. Budden <abu...@gmail.com> wrote:
> ...

>> I tried removing the HOME environment variable from cygwin (it's not set to anything in the Windows system, whereas it's set to /home/al in cygwin) and ran the command again from the cygwin terminal and it took a long time to start. I reset HOME to /home/al and it still took a long time to start! Opening a new cygwin terminal resulted in a quick start again. This is really weird!

(shot in the dark, have no MS Windows) what happens if you set a HOME
variable under Windows?

--
regards, jr.

You have the right to free speech, as long as you're not dumb enough
to actually try it.
(The Clash 'Know Your Rights')

[Andrew Bernard]

Take a look at Windows Event Viewer. You may be able to glean something from that.

Do you have an antivirus program running?

[A. S. Budden]

On Fri, 9 Sept 2022, 12:48 Andrew Bernard, <andrew....@gmail.com> wrote:

Take a look at Windows Event Viewer. You may be able to glean something from that.

I can't see anything obvious, but then I don't really know what I'm looking for.

Do you have an antivirus program running?

As far as I know, only the built in thing (windows defender)

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/eb996918-4d2a-4f6d-80d8-5f08a9d3d3ean%40googlegroups.com.

[A. S. Budden]

On Fri, 9 Sept 2022, 12:45 jr, <creature...@gmail.com> wrote:

hi,

On Fri, 9 Sept 2022 at 12:39, A. S. Budden  wrote:
> ...
>> I tried removing the HOME environment variable from cygwin (it's not set to anything in the Windows system, whereas it's set to /home/al in cygwin) and ran the command again from the cygwin terminal and it took a long time to start. I reset HOME to /home/al and it still took a long time to start! Opening a new cygwin terminal resulted in a quick start again. This is really weird!

(shot in the dark, have no MS Windows) what happens if you set a HOME
variable under Windows?

Oooh, that was a good shot! Setting the HOME environment variable seems to work (again, I've only tested this on one machine so far; I'll try the other tomorrow). It doesn't seem to matter what it's set to: I tried c:\cygwin\home\al and also just c:\ and it both cases Vim started very quickly.

Assuming it works on the other PC then that feels like a good & simple fix, but it'd be nice to understand why Vim goes slowly without HOME set to anything.

Thanks

Al

[jr]

On Mon, 12 Sept 2022 at 14:26, A. S. Budden <abu...@gmail.com> wrote:
> ...

> Oooh, that was a good shot! Setting the HOME environment variable seems to work (again, I've only tested this on one machine so far; I'll try the other tomorrow). It doesn't seem to matter what it's set to: I tried c:\cygwin\home\al and also just c:\ and it both cases Vim started very quickly.

great.

> Assuming it works on the other PC then that feels like a good & simple fix, but it'd be nice to understand why Vim goes slowly without HOME set to anything.

fwiw, "it'd be nice to understand" why Microsoft does without a HOME ;-).

[c.willis111]

It seems it is to do with their view of a file system. It's divided into HOMEDRIVE and HOMEPATH. It wd seem reasonable to insert a concatenation of these as HOME. I hesitate to offer a command, or where it sd go.

Chris Willis

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAM-dBgqFM4gXqkH8q3j96rvEtRTv5h%3Dd59O0w0FSu4vWh-bhuA%40mail.gmail.com.

[Andrew Bernard]

Looking at the source code for neovim (I'll check gvim later) I see the
following in a file called funcs.c that evaluates the environment
variables among other things:

/// According to comments in src/win/process.c of libuv, Windows has a few
/// "essential" environment variables.
static const char *required_env_vars[] = {
#ifdef WIN32
  "HOMEDRIVE",
  "HOMEPATH",
  "LOGONSERVER",
  "PATH",
  "SYSTEMDRIVE",
  "SYSTEMROOT",
  "TEMP",
  "USERDOMAIN",
  "USERNAME",
  "USERPROFILE",
  "WINDIR",
#endif
  NULL
};

But if you are running in cygwin I would have thought that shell only
uses a UNIX environment, so $HOME would be all that is needed. I have
not checked the logic of what happens when these variables are not set
in the code. [I'm not a vim developer - yet!]


Andrew

[jr]

On Mon, 12 Sept 2022 at 15:32, Andrew Bernard <andrew....@gmail.com> wrote:
> ...

> static const char *required_env_vars[] = {
> #ifdef WIN32
> "HOMEDRIVE",
> "HOMEPATH",

> ...

nice.

> But if you are running in cygwin I would have thought that shell only

> uses a UNIX environment, so $HOME would be all that is needed. ...

@A.S.Budden : ... and HOME and some other environment variables are
best treated as "read-only".

@c.willis111 : agree, and it would be interesting if someone who uses
the Windows environment variables (corporate, I guess) could "chime
in".

[A. S. Budden]

I've been running Vim with the HOME environment variable set for a couple of weeks now and it's remained consistently fast to start up.  As a test I went back to unsetting $HOME and it went back to being very slow to start, so there's definitely some combination of the way I've got vim set up (the lack of any configuration in %USERPROFILE%, the directory structure with c:\vim\vimfiles, c:\vim\runtime and c:\vim\gvim.exe) and the lack of a HOME environment variable that makes gvim decide to go extremely slowly.  I really like having the file structure as it is as I can have a copy of c:\vim (automatically synchronised) on a work network drive and if I have to use someone else's PC temporarily, it runs off the network drive with all of my configuration (albeit a bit slower due to the lack of $HOME and the fact it's loading everything over the network).

Having HOME set is a bit of a pain to be honest.  I tried just setting it to /home/al (as expected by cygwin, and set by cygwin if it's not set in the global environment), but that made TortoiseHg have a flap due to there being a cygwin symbolic link .hgrc in cygwin's /home/al, which TortoiseHg didn't understand.  If I set it to anything other than /home/al, cygwin decided that the $HOME location was my new home directory and ignored all my configuration.

I ended up with HOME set somewhere suitably random and with a whole load of edited cygwin startup stuff that made sure HOME was set to /home/al in cygwin regardless of what Windows had set in the global environment.

It would have been much easier if Vim started properly without $HOME set, but I guess that's not going to be an easy thing to fix.  At least it works now.

Al