Re: Vim startup profiling

[Ken Takata]

Hi,

2017/10/25 Wed 21:28:50 UTC+9 Christian Brabandt wrote:
> Hi Ken,
> I briefly looked at your patch and have some feedback.
> 
> On Mi, 25 Okt 2017, Ken Takata wrote:
> 
> > Changes are:
> > * Merge the two patches into one.
> > * Update the document.
> > * Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
> >   I'm still wondering what is the best name for this variable.
> > * Remove `has('win16')`.  Not needed anymore.
> > * Add  to the "Show File Types in Menu" item.  Showing the command
> >   of this item is not so useful.
> 
> +If you want to have all these items already present at startup, add: >
> +:let do_lazyload_menus = 1
> 
> I think this variable should either be called `do_no_lazyload_menus` or 
> the value should be 0, since by default the menus will be lazy loaded.

Okay, I changed it to `do_no_lazyload_menus`:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/cda66cbfc90b98a5ca6c16229ee129fd448c1bad/improve-loading-menu.vim.patch?fileviewer=file-view-default

Actually, menu.vim only checks the existence of the global variable, the value
is not checked.  This is the same as other variable in menu.vim.


> +  let n = globpath(, "colors/*.vim")
> 
> I think that should be
> 
> +  let n = globpath(, "colors/*.vim", 1, 1)
> 
> So you have a list available already and don't need to split later on 
> manually and you probably do want to ignore the suffixes and wildignore 
> options, if only the user having set them to bad values.
> 
> The same holds for the keymap and compiler runtime files.

It makes the code simpler.  Updated.


> +  augroup SetupLazyloadMenus
> +au!
> +au CursorHold,CursorHoldI * call SetupLazyloadMenus() | au! 
> SetupLazyloadMenus
> +  augroup END
> 
> Is this actually a good idea to delete the augroup from within itself?

Deleting autocommands in the group is a usual usage.  The similar usage can be
found in `augroup LoadBufferMenu` in menu.vim.  Moreover, just using `au!`
in an augroup is a normal usage.  Deleting an autogroup within itself by
`augroup!` doesn't work in contrast.  It causes W19 or E936.
Actually, I want to delete the group here...


> BTW: there are many runtime file variables. Perhaps we should start to 
> document internal runtime file variables in a help file at a central 
> place.
> 
> Also I am starting to wonder, whether it would make sense to start using 
> a common prefix, so that the names are more consistent and less likely 
> to clash with user variables, e.g. something like
> vim_ftplugin_undo
> vim_indent_undo
> vim_menu_init_immediate

Regards,
Ken Takata

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Christian Brabandt]

Hi Ken,
I briefly looked at your patch and have some feedback.

On Mi, 25 Okt 2017, Ken Takata wrote:

> Changes are:
> * Merge the two patches into one.
> * Update the document.
> * Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
>   I'm still wondering what is the best name for this variable.
> * Remove `has('win16')`.  Not needed anymore.
> * Add  to the "Show File Types in Menu" item.  Showing the command
>   of this item is not so useful.

+If you want to have all these items already present at startup, add: >
+:let do_lazyload_menus = 1

I think this variable should either be called `do_no_lazyload_menus` or 
the value should be 0, since by default the menus will be lazy loaded.

+  let n = globpath(, "colors/*.vim")

I think that should be

+  let n = globpath(, "colors/*.vim", 1, 1)

So you have a list available already and don't need to split later on 
manually and you probably do want to ignore the suffixes and wildignore 
options, if only the user having set them to bad values.

The same holds for the keymap and compiler runtime files.

+  augroup SetupLazyloadMenus
+au!
+au CursorHold,CursorHoldI * call SetupLazyloadMenus() | au! 
SetupLazyloadMenus
+  augroup END

Is this actually a good idea to delete the augroup from within itself?

BTW: there are many runtime file variables. Perhaps we should start to 
document internal runtime file variables in a help file at a central 
place.

Also I am starting to wonder, whether it would make sense to start using 
a common prefix, so that the names are more consistent and less likely 
to clash with user variables, e.g. something like
vim_ftplugin_undo
vim_indent_undo
vim_menu_init_immediate

Christian
-- 
Neuer MS-Slogan:
Speicherst Du noch oder fluchst Du schon?

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Ken Takata]

Hi,

2017/10/25 Wed 6:20:09 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > > > 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > > > 096.000  072.000  025.000: sourcing 
> > > > > > D:\Logiciels\Vim\vim80\filetype.vim
> > > > > 
> > > > > menu.vim uses `globpath()` to search some kind of files under the
> > > > runtimepath.
> > > > > If you search `globpath` in menu.vim, you may find the following 
> > > > > lines:
> > > > > 
> > > > >   let s:n = globpath(, "colors/*.vim")
> > > > > let s:n = globpath(, "keymap/*.vim")
> > > > >   let s = globpath(, "spell/*." . enc . ".spl")
> > > > >   let s:n = globpath(, "compiler/*.vim")
> > > > > 
> > > > > Color schemes, keymaps, spell files and compiler plugins are searched 
> > > > > when
> > > > > menu.vim is loaded.
> > > > > This is why it takes long time to be loaded.
> > > > > 
> > > > > Unlike those items, file types are not listed automatically.  If a 
> > > > > user
> > > > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > > > If we use a similar way for color schemes etc., the startup time 
> > > > > would be
> > > > > reduced.
> > > > 
> > > > I wrote a patch for reduce the loading the of menu.vim by skip using
> > > > globpath().
> > > > 
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default=file-view-default
> > > > 
> > > > Instead of searching colors/*.vim and other files, the following 
> > > > menuitems are
> > > > added in the menu:
> > > > 
> > > > Edit > Show Color Schemes in Menu
> > > > Edit > Show Keymaps in Menu
> > > > Tools > Show Compiler Settings in Menu
> > > > 
> > > > If these menuitems are selected, all available colorschemes etc. are 
> > > > shown
> > > > in the menu.  If a user want to load them at startup, the following line
> > > > can be added in .vimrc:
> > > > :let do_globpath_menus = 1
> > > > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > > > 
> > > > 
> > > > In my environment, the loading time of menu.vim is:
> > > > Without this patch:  30 - 50 ms
> > > > Skip using globpath: 15 - 20 ms
> > > 
> > > Not a very big difference.  But still worth it if you never use those
> > > menus.
> > > 
> > > I wonder if we can do this lazily.  Thus fill in the missing entries
> > > when we start waiting for the user to type.  Should be around the same
> > > place where timers may be triggered.  Not sure if we can do it with an
> > > actual timer from the menu.vim script though.  Might need a special kind
> > > of timer.  Perhaps an "idle timer"?
> > 
> > How about this additional patch, then?
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default=file-view-default
> > 
> > This uses CursorHold to load the menuitems when idle.
> 
> I like the idea.  I'll wait for a few people to try it out.

I have updated the patches:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/c58b17bb22261436910d77dcda76409edd962ad5/improve-loading-menu.vim.patch?at=default=file-view-default

Changes are:
* Merge the two patches into one.
* Update the document.
* Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
  I'm still wondering what is the best name for this variable.
* Remove `has('win16')`.  Not needed anymore.
* Add  to the "Show File Types in Menu" item.  Showing the command
  of this item is not so useful.

Regards,
Ken Takata

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Bram Moolenaar]

Ken Takata wrote:

> > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > > 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > > 096.000  072.000  025.000: sourcing 
> > > > > D:\Logiciels\Vim\vim80\filetype.vim
> > > > 
> > > > menu.vim uses `globpath()` to search some kind of files under the
> > > runtimepath.
> > > > If you search `globpath` in menu.vim, you may find the following lines:
> > > > 
> > > >   let s:n = globpath(, "colors/*.vim")
> > > > let s:n = globpath(, "keymap/*.vim")
> > > >   let s = globpath(, "spell/*." . enc . ".spl")
> > > >   let s:n = globpath(, "compiler/*.vim")
> > > > 
> > > > Color schemes, keymaps, spell files and compiler plugins are searched 
> > > > when
> > > > menu.vim is loaded.
> > > > This is why it takes long time to be loaded.
> > > > 
> > > > Unlike those items, file types are not listed automatically.  If a user
> > > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > > If we use a similar way for color schemes etc., the startup time would 
> > > > be
> > > > reduced.
> > > 
> > > I wrote a patch for reduce the loading the of menu.vim by skip using
> > > globpath().
> > > 
> > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default=file-view-default
> > > 
> > > Instead of searching colors/*.vim and other files, the following 
> > > menuitems are
> > > added in the menu:
> > > 
> > >   Edit > Show Color Schemes in Menu
> > >   Edit > Show Keymaps in Menu
> > >   Tools > Show Compiler Settings in Menu
> > > 
> > > If these menuitems are selected, all available colorschemes etc. are shown
> > > in the menu.  If a user want to load them at startup, the following line
> > > can be added in .vimrc:
> > >   :let do_globpath_menus = 1
> > > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > > 
> > > 
> > > In my environment, the loading time of menu.vim is:
> > >   Without this patch:  30 - 50 ms
> > >   Skip using globpath: 15 - 20 ms
> > 
> > Not a very big difference.  But still worth it if you never use those
> > menus.
> > 
> > I wonder if we can do this lazily.  Thus fill in the missing entries
> > when we start waiting for the user to type.  Should be around the same
> > place where timers may be triggered.  Not sure if we can do it with an
> > actual timer from the menu.vim script though.  Might need a special kind
> > of timer.  Perhaps an "idle timer"?
> 
> How about this additional patch, then?
> https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default=file-view-default
> 
> This uses CursorHold to load the menuitems when idle.

I like the idea.  I'll wait for a few people to try it out.

-- 
Trees moving back and forth is what makes the wind blow.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Ken Takata]

Hi Bram,

2017/10/24 Tue 5:45:40 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > 096.000  072.000  025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> > > 
> > > menu.vim uses `globpath()` to search some kind of files under the
> > runtimepath.
> > > If you search `globpath` in menu.vim, you may find the following lines:
> > > 
> > >   let s:n = globpath(, "colors/*.vim")
> > > let s:n = globpath(, "keymap/*.vim")
> > >   let s = globpath(, "spell/*." . enc . ".spl")
> > >   let s:n = globpath(, "compiler/*.vim")
> > > 
> > > Color schemes, keymaps, spell files and compiler plugins are searched when
> > > menu.vim is loaded.
> > > This is why it takes long time to be loaded.
> > > 
> > > Unlike those items, file types are not listed automatically.  If a user
> > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > If we use a similar way for color schemes etc., the startup time would be
> > > reduced.
> > 
> > I wrote a patch for reduce the loading the of menu.vim by skip using
> > globpath().
> > 
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default=file-view-default
> > 
> > Instead of searching colors/*.vim and other files, the following menuitems 
> > are
> > added in the menu:
> > 
> > Edit > Show Color Schemes in Menu
> > Edit > Show Keymaps in Menu
> > Tools > Show Compiler Settings in Menu
> > 
> > If these menuitems are selected, all available colorschemes etc. are shown
> > in the menu.  If a user want to load them at startup, the following line
> > can be added in .vimrc:
> > :let do_globpath_menus = 1
> > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > 
> > 
> > In my environment, the loading time of menu.vim is:
> > Without this patch:  30 - 50 ms
> > Skip using globpath: 15 - 20 ms
> 
> Not a very big difference.  But still worth it if you never use those
> menus.
> 
> I wonder if we can do this lazily.  Thus fill in the missing entries
> when we start waiting for the user to type.  Should be around the same
> place where timers may be triggered.  Not sure if we can do it with an
> actual timer from the menu.vim script though.  Might need a special kind
> of timer.  Perhaps an "idle timer"?

How about this additional patch, then?
https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default=file-view-default

This uses CursorHold to load the menuitems when idle.

Regards,
Ken Takata

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Bram Moolenaar]

Ken Takata wrote:

> 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > 096.000  072.000  025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> > 
> > menu.vim uses `globpath()` to search some kind of files under the
> runtimepath.
> > If you search `globpath` in menu.vim, you may find the following lines:
> > 
> >   let s:n = globpath(, "colors/*.vim")
> > let s:n = globpath(, "keymap/*.vim")
> >   let s = globpath(, "spell/*." . enc . ".spl")
> >   let s:n = globpath(, "compiler/*.vim")
> > 
> > Color schemes, keymaps, spell files and compiler plugins are searched when
> > menu.vim is loaded.
> > This is why it takes long time to be loaded.
> > 
> > Unlike those items, file types are not listed automatically.  If a user
> > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > If we use a similar way for color schemes etc., the startup time would be
> > reduced.
> 
> I wrote a patch for reduce the loading the of menu.vim by skip using
> globpath().
> 
> https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default=file-view-default
> 
> Instead of searching colors/*.vim and other files, the following menuitems are
> added in the menu:
> 
>   Edit > Show Color Schemes in Menu
>   Edit > Show Keymaps in Menu
>   Tools > Show Compiler Settings in Menu
> 
> If these menuitems are selected, all available colorschemes etc. are shown
> in the menu.  If a user want to load them at startup, the following line
> can be added in .vimrc:
>   :let do_globpath_menus = 1
> (This is similar to `:let do_syntax_sel_menu = 1`.)
> 
> 
> In my environment, the loading time of menu.vim is:
>   Without this patch:  30 - 50 ms
>   Skip using globpath: 15 - 20 ms

Not a very big difference.  But still worth it if you never use those
menus.

I wonder if we can do this lazily.  Thus fill in the missing entries
when we start waiting for the user to type.  Should be around the same
place where timers may be triggered.  Not sure if we can do it with an
actual timer from the menu.vim script though.  Might need a special kind
of timer.  Perhaps an "idle timer"?

-- 
With sufficient thrust, pigs fly just fine.
   -- RFC 1925

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Ken Takata]

Hi,

2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > 096.000  072.000  025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> 
> menu.vim uses `globpath()` to search some kind of files under the
runtimepath.
> If you search `globpath` in menu.vim, you may find the following lines:
> 
>   let s:n = globpath(, "colors/*.vim")
> let s:n = globpath(, "keymap/*.vim")
>   let s = globpath(, "spell/*." . enc . ".spl")
>   let s:n = globpath(, "compiler/*.vim")
> 
> Color schemes, keymaps, spell files and compiler plugins are searched when
> menu.vim is loaded.
> This is why it takes long time to be loaded.
> 
> Unlike those items, file types are not listed automatically.  If a user
> selects "Syntax" -> "Show File Types in Menu", they will be listed.
> If we use a similar way for color schemes etc., the startup time would be
> reduced.

I wrote a patch for reduce the loading the of menu.vim by skip using
globpath().

https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default=file-view-default

Instead of searching colors/*.vim and other files, the following menuitems are
added in the menu:

Edit > Show Color Schemes in Menu
Edit > Show Keymaps in Menu
Tools > Show Compiler Settings in Menu

If these menuitems are selected, all available colorschemes etc. are shown
in the menu.  If a user want to load them at startup, the following line
can be added in .vimrc:
:let do_globpath_menus = 1
(This is similar to `:let do_syntax_sel_menu = 1`.)


In my environment, the loading time of menu.vim is:
Without this patch:  30 - 50 ms
Skip using globpath: 15 - 20 ms

Regards,
Ken Takata

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Christian Brabandt]

On Fr, 26 Mai 2017, Ken Takata wrote:

> > Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> > Is anyone can advise me or explain to me why some  files are loaded twice 
> > and take twice or more times N msec:
> > - vim80/menu.vim
> > - vim80\filetype.vim
> 
> > 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > 096.000  072.000  025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> 
> menu.vim uses `globpath()` to search some kind of files under the runtimepath.
> If you search `globpath` in menu.vim, you may find the following lines:
> 
>   let s:n = globpath(, "colors/*.vim")
> let s:n = globpath(, "keymap/*.vim")
>   let s = globpath(, "spell/*." . enc . ".spl")
>   let s:n = globpath(, "compiler/*.vim")
> 
> Color schemes, keymaps, spell files and compiler plugins are searched when
> menu.vim is loaded.
> This is why it takes long time to be loaded.
> 
> Unlike those items, file types are not listed automatically.  If a user
> selects "Syntax" -> "Show File Types in Menu", they will be listed.
> If we use a similar way for color schemes etc., the startup time would be
> reduced.

I took a brief look into that. First, I don't think it would be easily 
possible to avoid the globpath() for the colorschemes and other scripts. 

The syntax script seems to be compile time dependent, so while this 
works, I assume it does not work correctly for filetypes/syntax scripts 
you installed as extra package and I guess this is not what we want for 
colorschemes and the other script types.

I think, it could be beneficial, if globpath() and glob() did allow for 
e.g. OR'ing the script, e.g. something like this should be a lot faster:

globpath(, "{colors,spell,keymap,compiler}/*.vim")

Because we could then manually filter the resulting list. Unfortunately, 
this syntax is not supported by glob()/globpath(). That could be a 
worthwhile addition.

Mit freundlichen Grüßen
Christian
-- 
Machen Sie sich erst einmal unbeliebt, dann werden Sie auch ernst
genommen.
-- Konrad Adenauer

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Ken Takata]

Hi,

2017/5/24 Wed 17:39:34 UTC+9 Ni Va wrote:
> Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit :
> > Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit :
> > > > Thank you
> > > Sped up by using a plugin manager supporting lazy loading or as needed
> > > (vim-addon-manager/Neobundle  maybe more).
> > > 
> > > Typically sourcing twice is not a problem, often guard [1] like guard
> > > has been setup which is a quick workraound which immediately saves most
> > > time.
> > > 
> > > Marc Weber
> > > 
> > > [1]
> > > 
> > >   if exists("loaded_")
> > > finish
> > >   endif
> > >   let loaded_ = 1
> > > 
> > >   
> > 
> > Ok this one seems better than vundle and save me 100ms at startup but I dig.
> > https://github.com/junegunn/vim-plug
> > 
> > Thank you Marc !
> 
> Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> Is anyone can advise me or explain to me why some  files are loaded twice and 
> take twice or more times N msec:
> - vim80/menu.vim
> - vim80\filetype.vim

> 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> 096.000  072.000  025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim

menu.vim uses `globpath()` to search some kind of files under the runtimepath.
If you search `globpath` in menu.vim, you may find the following lines:

  let s:n = globpath(, "colors/*.vim")
let s:n = globpath(, "keymap/*.vim")
  let s = globpath(, "spell/*." . enc . ".spl")
  let s:n = globpath(, "compiler/*.vim")

Color schemes, keymaps, spell files and compiler plugins are searched when
menu.vim is loaded.
This is why it takes long time to be loaded.

Unlike those items, file types are not listed automatically.  If a user
selects "Syntax" -> "Show File Types in Menu", they will be listed.
If we use a similar way for color schemes etc., the startup time would be
reduced.

Regards,
Ken Takata

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Ni Va]

Le mercredi 24 mai 2017 21:54:12 UTC+2, Christian Brabandt a écrit :
> On Mi, 24 Mai 2017, Antony Scriven wrote:
> 
> > Your colorscheme or vimrc or both appears to be causing
> > syncolor.vim to go bananas. I'd take a look at the code
> > there to find out what's going on. filetype.vim and menu.vim
> > are just big. You can disable loading menu.vim with `set
> > guioptions+=M` if you don't need it. 
> 
> Yes, and it must be set before the menu vim script is loaded, so before 
> any filetype or :syn on commands in your vimrc, so it should be done 
> relatively early in
> 
> Best,
> Christian
> -- 
> Das X ist der Klappstuhl des Alphabets.
>   -- Ramòn Gómez de la Serna

Ok Christian I have lift my _vimrc joined here if you have time to look at.
Thank you !

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


_vimrc
Description: Binary data

Re: Vim startup profiling

[Christian Brabandt]

On Mi, 24 Mai 2017, Antony Scriven wrote:

> Your colorscheme or vimrc or both appears to be causing
> syncolor.vim to go bananas. I'd take a look at the code
> there to find out what's going on. filetype.vim and menu.vim
> are just big. You can disable loading menu.vim with `set
> guioptions+=M` if you don't need it. 

Yes, and it must be set before the menu vim script is loaded, so before 
any filetype or :syn on commands in your vimrc, so it should be done 
relatively early in

Best,
Christian
-- 
Das X ist der Klappstuhl des Alphabets.
-- Ramòn Gómez de la Serna

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Ni Va]

Le mercredi 24 mai 2017 11:01:31 UTC+2, Dominique Pelle a écrit :
> Ni Va :
> 
> > Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit :
> >> Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit :
> >> > > Thank you
> >> > Sped up by using a plugin manager supporting lazy loading or as needed
> >> > (vim-addon-manager/Neobundle  maybe more).
> >> >
> >> > Typically sourcing twice is not a problem, often guard [1] like guard
> >> > has been setup which is a quick workraound which immediately saves most
> >> > time.
> >> >
> >> > Marc Weber
> >> >
> >> > [1]
> >> >
> >> >   if exists("loaded_")
> >> > finish
> >> >   endif
> >> >   let loaded_ = 1
> >> >
> >> >   
> >>
> >> Ok this one seems better than vundle and save me 100ms at startup but I 
> >> dig.
> >> https://github.com/junegunn/vim-plug
> >>
> >> Thank you Marc !
> >
> > Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> > Is anyone can advise me or explain to me why some  files are loaded twice 
> > and take twice or more times N msec:
> > - vim80/menu.vim
> > - vim80\filetype.vim
> 
> 
> I did not have the time to analyze your problem,
> but I recall vaguely that if your ~/.vimrc contains
> the "colorscheme" command, it should be at the
> end of the .vimrc otherwise some scripts are sourced
> twice. Sorry if this is vague, I don't remember the
> details and I don't have the time to look at it now.
> But perhaps it helps anyway.
> 
> Dominique

Ok thank you for your advices Dominique And Anthony.
Good Journey

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Marc Weber]

> Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> Is anyone can advise me or explain to me why some  files are loaded twice and 
> take twice or more times N msec:
> - vim80/menu.vim
> - vim80\filetype.vim

I never compared vimplug vs VAM, but I'd be interested in it.
AFAIK parsing commands such as Plug takes time, you may want to lookup
its definition and call that code in .vimrc instead - maybe it saves you 1 ms.


VAM is only 770 lines - because we split the 'everyday runtime code' and
the 'update/install' code. This eventually could be done for VimPlug as
well.

If you want to give VAM a try you can create dictionaries like this:

  {'filetype_regex': '\%(rb)$', 'names': ['vim-ruby', 'vim-addon-rdebug', 
'vim-addon-ruby-debug-ide', 'textobj-rubyblock' ]}
  {'name': 'matchit.zip'}

and write such a file and load by

  call vam#Scripts(expand('~/.vim-scripts'), {})

github:repo/name can be used as names.

I don't say use VAM, but it could shed some light into whether you can be
faster and wheter VimPlug can be improved. It has features VAM does not
have - such as fixing version.

VAM has had an experimental mode 'merging all plugin/*' files into one
to seed things up - but its likely to break code such as did_load or
similar.

  See vam#install#MergePluginFiles( ..

But as far as I remember I stopped using it myself even before switching
to SSD / getting a faster machine.

Marc Weber

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Dominique Pellé]

Ni Va :

> Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit :
>> Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit :
>> > > Thank you
>> > Sped up by using a plugin manager supporting lazy loading or as needed
>> > (vim-addon-manager/Neobundle  maybe more).
>> >
>> > Typically sourcing twice is not a problem, often guard [1] like guard
>> > has been setup which is a quick workraound which immediately saves most
>> > time.
>> >
>> > Marc Weber
>> >
>> > [1]
>> >
>> >   if exists("loaded_")
>> > finish
>> >   endif
>> >   let loaded_ = 1
>> >
>> >   
>>
>> Ok this one seems better than vundle and save me 100ms at startup but I dig.
>> https://github.com/junegunn/vim-plug
>>
>> Thank you Marc !
>
> Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> Is anyone can advise me or explain to me why some  files are loaded twice and 
> take twice or more times N msec:
> - vim80/menu.vim
> - vim80\filetype.vim


I did not have the time to analyze your problem,
but I recall vaguely that if your ~/.vimrc contains
the "colorscheme" command, it should be at the
end of the .vimrc otherwise some scripts are sourced
twice. Sorry if this is vague, I don't remember the
details and I don't have the time to look at it now.
But perhaps it helps anyway.

Dominique

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Antony Scriven]

Your colorscheme or vimrc or both appears to be causing
syncolor.vim to go bananas. I'd take a look at the code
there to find out what's going on. filetype.vim and menu.vim
are just big. You can disable loading menu.vim with `set
guioptions+=M` if you don't need it. --Antony

2017-05-24 9:39 GMT+01:00 Ni Va :
> Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit :
>> Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit :
>> > > Thank you
>> > Sped up by using a plugin manager supporting lazy loading or as needed
>> > (vim-addon-manager/Neobundle  maybe more).
>> >
>> > Typically sourcing twice is not a problem, often guard [1] like guard
>> > has been setup which is a quick workraound which immediately saves most
>> > time.
>> >
>> > Marc Weber
>> >
>> > [1]
>> >
>> >   if exists("loaded_")
>> > finish
>> >   endif
>> >   let loaded_ = 1
>> >
>> >   
>>
>> Ok this one seems better than vundle and save me 100ms at startup but I dig.
>> https://github.com/junegunn/vim-plug
>>
>> Thank you Marc !
>
> Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> Is anyone can advise me or explain to me why some  files are loaded twice and 
> take twice or more times N msec:
> - vim80/menu.vim
> - vim80\filetype.vim
>
>
> Thank you
> _
>
> times in msec
>  clock   self+sourced   self:  sourced script
>  clock   elapsed:  other lines
>
> 000.000  000.000: --- VIM STARTING ---
> 000.000  000.000: Allocated generic buffers
> 002.000  002.000: locale set
> 004.000  002.000: GUI prepared
> 004.000  000.000: clipboard setup
> 004.000  000.000: window checked
> 004.000  000.000: inits 1
> 006.000  002.000: parsing arguments
> 006.000  000.000: expanding arguments
> 007.000  001.000: shell init
> 007.000  000.000: inits 2
> 008.000  001.000: init highlight
> 018.000  003.000  003.000: sourcing 
> D:\Logiciels\Vim/awesomeplugins/vim/vim-plug-master/plug.vim
> 043.000  000.000  000.000: sourcing 
> D:\Logiciels\Vim\awesomeplugins\vim\awl\ftdetect\awl.vim
> 044.000  000.000  000.000: sourcing 
> D:\Logiciels\Vim\awesomeplugins\vim\sonictemplate-vim\ftdetect\stpl.vim
> 045.000  000.000  000.000: sourcing 
> D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\ps1.vim
> 046.000  000.000  000.000: sourcing 
> D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\ps1xml.vim
> 047.000  000.000  000.000: sourcing 
> D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\xml.vim
> 052.000  001.000  001.000: sourcing 
> D:\Logiciels\Vim\vim80\lang/menu_fr_fr.latin1.vim
> 052.000  002.000  001.000: sourcing 
> D:\Logiciels\Vim\vim80\lang\menu_fr.latin1.vim
> 054.000  001.000  001.000: sourcing D:\Logiciels\Vim\vim80\autoload\paste.vim
> 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> 096.000  072.000  025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> 097.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\ftplugin.vim
> 099.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\indent.vim
> 104.000  002.000  002.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 104.000  003.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
> 104.000  004.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
> 119.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
> 122.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 122.000  001.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
> 122.000  004.000  003.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
> 124.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
> 127.000  001.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 127.000  002.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
> 127.000  004.000  002.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
> 128.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> 129.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\ftplugin.vim
> 130.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\indent.vim
> 132.000  001.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
> 134.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 135.000  002.000  002.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
> 135.000  004.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
> 138.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 140.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 142.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 142.000  005.000  005.000: sourcing 
> D:\Logiciels\Vim\vimfiles\colors\nivacolors.vim
> 143.000  134.000  038.000: sourcing $VIM\_vimrc
> 143.000  001.000: sourcing vimrc file(s)
> 144.000  000.000  000.000: sourcing 
> D:\Logiciels\Vim\awesomeplugins\vim\awl\plugin\awl.vim
> 145.000  000.000  

Re: Vim startup profiling

[Ni Va]

Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit :
> Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit :
> > > Thank you
> > Sped up by using a plugin manager supporting lazy loading or as needed
> > (vim-addon-manager/Neobundle  maybe more).
> > 
> > Typically sourcing twice is not a problem, often guard [1] like guard
> > has been setup which is a quick workraound which immediately saves most
> > time.
> > 
> > Marc Weber
> > 
> > [1]
> > 
> >   if exists("loaded_")
> > finish
> >   endif
> >   let loaded_ = 1
> > 
> >   
> 
> Ok this one seems better than vundle and save me 100ms at startup but I dig.
> https://github.com/junegunn/vim-plug
> 
> Thank you Marc !

Ok I save 100ms using the plugin manager vim-plug but not enough for me.
Is anyone can advise me or explain to me why some  files are loaded twice and 
take twice or more times N msec:
- vim80/menu.vim
- vim80\filetype.vim


Thank you
_

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:  other lines

000.000  000.000: --- VIM STARTING ---
000.000  000.000: Allocated generic buffers
002.000  002.000: locale set
004.000  002.000: GUI prepared
004.000  000.000: clipboard setup
004.000  000.000: window checked
004.000  000.000: inits 1
006.000  002.000: parsing arguments
006.000  000.000: expanding arguments
007.000  001.000: shell init
007.000  000.000: inits 2
008.000  001.000: init highlight
018.000  003.000  003.000: sourcing 
D:\Logiciels\Vim/awesomeplugins/vim/vim-plug-master/plug.vim
043.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\awl\ftdetect\awl.vim
044.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\sonictemplate-vim\ftdetect\stpl.vim
045.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\ps1.vim
046.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\ps1xml.vim
047.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\xml.vim
052.000  001.000  001.000: sourcing 
D:\Logiciels\Vim\vim80\lang/menu_fr_fr.latin1.vim
052.000  002.000  001.000: sourcing 
D:\Logiciels\Vim\vim80\lang\menu_fr.latin1.vim
054.000  001.000  001.000: sourcing D:\Logiciels\Vim\vim80\autoload\paste.vim
096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
096.000  072.000  025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
097.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\ftplugin.vim
099.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\indent.vim
104.000  002.000  002.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
104.000  003.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
104.000  004.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
119.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
122.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
122.000  001.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
122.000  004.000  003.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
124.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
127.000  001.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
127.000  002.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
127.000  004.000  002.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
128.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
129.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\ftplugin.vim
130.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\indent.vim
132.000  001.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
134.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
135.000  002.000  002.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
135.000  004.000  001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
138.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
140.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
142.000  000.000  000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
142.000  005.000  005.000: sourcing 
D:\Logiciels\Vim\vimfiles\colors\nivacolors.vim
143.000  134.000  038.000: sourcing $VIM\_vimrc
143.000  001.000: sourcing vimrc file(s)
144.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\awl\plugin\awl.vim
145.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\backup\plugin\backup.vim
146.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\codi.vim-master\plugin\codi.vim
147.000  000.000  000.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\comfortable-motion.vim\plugin\comfortable_motion.vim
150.000  001.000  001.000: sourcing 
D:\Logiciels\Vim\awesomeplugins\vim\ctrlp.vim-master\autoload\ctrlp\mrufiles.vim
150.000  002.000  001.000: sourcing 

Re: Vim startup profiling

[Ni Va]

Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit :
> > Thank you
> Sped up by using a plugin manager supporting lazy loading or as needed
> (vim-addon-manager/Neobundle  maybe more).
> 
> Typically sourcing twice is not a problem, often guard [1] like guard
> has been setup which is a quick workraound which immediately saves most
> time.
> 
> Marc Weber
> 
> [1]
> 
>   if exists("loaded_")
> finish
>   endif
>   let loaded_ = 1
> 
>   

Ok this one seems better than vundle and save me 100ms at startup but I dig.
https://github.com/junegunn/vim-plug

Thank you Marc !

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Marc Weber]

> Thank you
Sped up by using a plugin manager supporting lazy loading or as needed
(vim-addon-manager/Neobundle  maybe more).

Typically sourcing twice is not a problem, often guard [1] like guard
has been setup which is a quick workraound which immediately saves most
time.

Marc Weber

[1]

  if exists("loaded_")
finish
  endif
  let loaded_ = 1

  

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.