On Sat, Nov 11, 2006 at 10:53:03AM +0100, Donald Axel wrote:
>
>
> This is not a specifically Gvim related question though I
> experienced this first with gvim.
>
> After compiling and installing xen-3.0.3_0-src on a SL-43 system I
> tried to read some file with gvim and it took 5 minutes or slightly
> more to open the file and display its content.
>
> SL-43: Scientific Linux version 4.3.
>
> As this of course was very intriguing (read-arm clicking for a long
> time) I tried to follow what files were opened with
>
> "lsof -p XXXX"
>
> It showed that the gvim-process walked through the entire
> "xen-3.0.3_0-src" tree opening and closing files.
>
> After I moved this tree time for loading gvim was reduced to some 5
> seconds first time and 0 seconds on next load.
>
> Same applies to gxine (and probably other multimedia applications).
>
> What can cause a program to search through the whole tree of the
> source of an installed software package?
There are lots of things that could cause this. For example, a
line like
:vimgrep /todo/g /path/to/xen-3.0.3_0-src/**/*.c
in your vimrc file or any automatically-loaded plugin would do it. I
suggest trying
$ gvim -u NONE
If this cures the problem, then there is some such wasteful line,
perhaps in the system vimrc file, and you can try to track it down. If
the problem persists, then something else is causing it.
If you are using vim 7.0, then you can also try adding
:set verbose=20 verbosefile=~/vimlog.txt
to your vimrc file and then
$ gvim
Get a cup of coffe, then
:e ~/vimlog.txt
> Xen did not add to /etc/ld.so.conf.d or ld.so.conf or change any
> other conf-file in /etc. I will also ask on the Xen lists whether this
> behaviour is known.
AFAIK, vim does not check for configuration files there. Try
:scriptnames
to see what files have been :source'd and look at the end of the
:version
output to see where your system vimrc file (if any) is.
HTH --Benji Fisher
