Improving vim startuptime

159 views
Skip to first unread message

Manas

unread,
Jul 16, 2023, 12:57:38 PM7/16/23
to v...@vim.org
Hey folks, today I ran hyperfine on vim and found my startuptime is way
too slow.

Benchmark 1: /usr/bin/vim
Time (mean ± σ): 2.707 s ± 0.036 s [User: 0.598 s, System: 0.097 s]
Range (min … max): 2.674 s … 2.779 s 10 runs


Are there any tips on improving this?

--
Manas

Gary Johnson

unread,
Jul 16, 2023, 1:56:58 PM7/16/23
to vim...@googlegroups.com
It depends, of course, on why it is slow. You can start vim with
the --startuptime option to get a better idea of where the slowdown
is. See ":help --startuptime".

For example, starting vim on my Cygwin system was really slow
because I wrote my vimrc and some plugins as I would for Unix, where
running external programs is really fast. I re-wrote those to make
less use of external programs.

As another example, starting vim on a remote Linux machine via ssh
and X from a local Linux machine can be slow if the connection is
slow because vim communicates with the X server and the terminal on
the local machine. I don't know what to do in that case other than
be patient or start vim with -X and forgo some of the features of X.

HTH,
Gary

Tony Mechelynck

unread,
Jul 16, 2023, 1:58:27 PM7/16/23
to vim...@googlegroups.com, v...@vim.org
And you think 2.7 seconds is unbearably long? I suppose I'm
old-fashioned. When I started programming on a mainframe in the
seventies (131072 six-bit characters, no virtual memory, no
floating-point computations, no lowercase printing, 667 kHz, and it
needed an air-conditioned hall bigger than the apartment I live in
today) it took way longer than that to load a test program from its
executable tape. Even after downloading the tested version to disk,
three seconds would have been lightning-quick. Oh well, times change
after all.

Try getting (or compiling) a minimal version of Vim without GUI
(possibly called "vi") then load it as "vi -u NONE -N". Maybe you will
regret its lack of features, and in particular its lack of GUI and its
lack of configuration possibilities, but I expect it will load
significantly faster. After you test it for some time, then maybe you
will decide that 2.7 seconds wasn't so bad after all for the features
you enjoyed. Or maybe you will be so enthusiastic about having a
zip-fast (if feature-poor) Vim that you'll stay with it.

Best regards,
Tony.

Dominique Pellé

unread,
Jul 16, 2023, 2:35:22 PM7/16/23
to vim...@googlegroups.com
That's slow. It should be faster. Try this:

$ vim --startuptime startuptime.log

And send us the created startuptime.log which should help
understanding where the time is spent.

Dominique

Manas

unread,
Jul 16, 2023, 3:01:15 PM7/16/23
to vim...@googlegroups.com
On Sun, Jul 16, 2023 at 10:55:04AM -0700, Gary Johnson wrote:
> It depends, of course, on why it is slow. You can start vim with
> the --startuptime option to get a better idea of where the slowdown
> is. See ":help --startuptime".
>
> For example, starting vim on my Cygwin system was really slow
> because I wrote my vimrc and some plugins as I would for Unix, where
> running external programs is really fast. I re-wrote those to make
> less use of external programs.
>
> As another example, starting vim on a remote Linux machine via ssh
> and X from a local Linux machine can be slow if the connection is
> slow because vim communicates with the X server and the terminal on
> the local machine. I don't know what to do in that case other than
> be patient or start vim with -X and forgo some of the features of X.
`startuptime` surprisingly shows me a mere 656ms, while hyperfine shows
me 2.7s. I am not sure how this discrepancy is arising. Here is the full
log. https://pastebin.mozilla.org/uTrJ7i8N

I see 234ms (out of those 656ms, ~35%) due to VimEnter autocommands. My
autocommands are just scattered throughout vimrc. Most of them are like:

au FileType <list> [mappings|calls]

Maybe there is a way to organize them better?

And there are a ton of plugins too. Is there any way to only source them
conditionally?

I can also try removing some of the old plugins. I haven't done a
cleanup in a while.

--
Manas

Manas

unread,
Jul 16, 2023, 3:06:19 PM7/16/23
to vim...@googlegroups.com, v...@vim.org
On Sun, Jul 16, 2023 at 07:58:07PM +0200, Tony Mechelynck wrote:
> And you think 2.7 seconds is unbearably long? I suppose I'm
> old-fashioned. When I started programming on a mainframe in the
> seventies (131072 six-bit characters, no virtual memory, no
> floating-point computations, no lowercase printing, 667 kHz, and it
> needed an air-conditioned hall bigger than the apartment I live in
> today) it took way longer than that to load a test program from its
> executable tape. Even after downloading the tested version to disk,
> three seconds would have been lightning-quick. Oh well, times change
> after all.
I am glad I wasn't born in the seventies then. Though the music was
awesome. ;)

> Try getting (or compiling) a minimal version of Vim without GUI
> (possibly called "vi") then load it as "vi -u NONE -N". Maybe you will
> regret its lack of features, and in particular its lack of GUI and its
> lack of configuration possibilities, but I expect it will load
> significantly faster. After you test it for some time, then maybe you
> will decide that 2.7 seconds wasn't so bad after all for the features
> you enjoyed. Or maybe you will be so enthusiastic about having a
> zip-fast (if feature-poor) Vim that you'll stay with it.
Well that's a way to go, but I really don't want to maintain my own
separate repo, as I don't even contribute to the upstream project in any
way. I am enjoying relying on my package manager to keep me updated.

--
Manas

Gary Johnson

unread,
Jul 16, 2023, 4:03:15 PM7/16/23
to vim...@googlegroups.com
All of those things are possible and probably good ideas, but
driving them all to zero would improve the time by only 656 ms and
still leaves you with an annoying 2.1 s unaccounted for.

The output of hyperfine shows only the program name. What command
are you executing? If the command was something like this,

vim -cq

then I can't explain what vim could be doing from the time it
printed "--- VIM STARTED ---" in the log until it exited.

It would be interesting to see what hyperfine measures with the
command

vim -N -u NONE -i NONE -X -cq

Regards,
Gary

Dominique Pellé

unread,
Jul 16, 2023, 4:10:48 PM7/16/23
to vim...@googlegroups.com
In your startup file, I see:

374.858 001.193 001.193: sourcing
/home/neon/.vim/plugged/vim-gutentags/autoload/gutentags.vim
377.927 002.447 002.447: sourcing
/home/neon/.vim/plugged/YouCompleteMe/autoload/youcompleteme.vim
610.942 000.370 000.370: sourcing
/home/neon/.vim/plugged/context.vim/autoload/context/line.vim
611.846 234.541: VimEnter autocommands
611.854 000.008: before starting main loop

I don't understand how this works.
Isn't it youcompleteme.vim which is slow? since the timestamp
goes from 377.927ms to 610.942 ms.

In the original post, you said that startup took 2.6 sec but we see
it's much faster than that from vim --startup.

In my set up, youcompleteme.vim also seems to be the slowest step.
But it's faster than for you.

Did you build with -O2? Consider posting the output of
the `vim --version` command.

For comparison, this is my startup log file on
xubuntu-22.04 \(remotely access via ssh):

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

000.008 000.008: --- VIM STARTING ---
000.091 000.083: Allocated generic buffers
000.112 000.021: locale set
000.117 000.005: clipboard setup
000.122 000.005: window checked
000.447 000.325: inits 1
000.460 000.013: parsing arguments
000.461 000.001: expanding arguments
000.483 000.022: shell init
000.760 000.277: Termcap init
000.770 000.010: inits 2
000.841 000.071: init highlight
002.326 001.271 001.271: sourcing /home/dope/.vim/autoload/plug.vim
010.277 000.051 000.051: sourcing
/home/dope/.vim/plugged/csv.vim/ftdetect/csv.vim
010.444 000.017 000.017: sourcing
/home/dope/.vim/plugged/vim-qml/ftdetect/qml.vim
010.591 000.019 000.019: sourcing
/home/dope/.vim/plugged/vim-fugitive/ftdetect/fugitive.vim
010.716 000.026 000.026: sourcing
/home/dope/.vim/plugged/kotlin-vim/ftdetect/kotlin.vim
010.846 005.124 005.011: sourcing /usr/local/share/vim/vim90/filetype.vim
011.078 000.073 000.073: sourcing /usr/local/share/vim/vim90/ftplugin.vim
011.299 000.063 000.063: sourcing /usr/local/share/vim/vim90/indent.vim
012.922 000.630 000.630: sourcing
/usr/local/share/vim/vim90/colors/lists/default.vim
013.010 001.263 000.633: sourcing
/usr/local/share/vim/vim90/syntax/syncolor.vim
013.083 001.510 000.247: sourcing
/usr/local/share/vim/vim90/syntax/synload.vim
013.140 001.771 000.261: sourcing /usr/local/share/vim/vim90/syntax/syntax.vim
013.638 000.237 000.237: sourcing
/usr/local/share/vim/vim90/syntax/nosyntax.vim
014.157 000.141 000.141: sourcing
/usr/local/share/vim/vim90/syntax/syncolor.vim
014.234 000.417 000.276: sourcing
/usr/local/share/vim/vim90/syntax/synload.vim
014.288 000.978 000.324: sourcing /usr/local/share/vim/vim90/syntax/syntax.vim
014.450 000.017 000.017: sourcing /usr/local/share/vim/vim90/filetype.vim
014.658 000.020 000.020: sourcing /usr/local/share/vim/vim90/ftplugin.vim
032.776 000.550 000.550: sourcing
/usr/local/share/vim/vim90/colors/lists/default.vim
033.222 000.134 000.134: sourcing
/usr/local/share/vim/vim90/syntax/syncolor.vim
033.639 000.144 000.144: sourcing
/usr/local/share/vim/vim90/syntax/syncolor.vim
034.044 001.196 000.918: sourcing
/home/dope/.vim/plugged/rastafari/colors/rastafari.vim
034.049 033.064 022.001: sourcing $HOME/.vimrc
034.053 000.148: sourcing vimrc file(s)
034.294 000.098 000.098: sourcing
/home/dope/.vim/plugged/vim-gtest/plugin/gtest.vim
034.571 000.193 000.193: sourcing
/home/dope/.vim/plugged/csv.vim/plugin/csv.vim
035.458 000.800 000.800: sourcing
/home/dope/.vim/plugged/vim-alternate/plugin/a.vim
035.655 000.086 000.086: sourcing
/home/dope/.vim/plugged/vim-Grammalecte/plugin/Grammalecte.vim
035.818 000.076 000.076: sourcing
/home/dope/.vim/plugged/vim-LanguageTool/plugin/LanguageTool.vim
036.066 000.153 000.153: sourcing
/home/dope/.vim/plugged/vim-asterisk/plugin/asterisk.vim
036.341 000.183 000.183: sourcing
/home/dope/.vim/plugged/CommandlineComplete.vim/plugin/commandline_complete.vim
037.040 000.579 000.579: sourcing /home/dope/.vim/plugged/fzf/plugin/fzf.vim
037.934 000.775 000.775: sourcing
/home/dope/.vim/plugged/fzf.vim/plugin/fzf.vim
038.271 000.113 000.113: sourcing
/home/dope/.vim/plugged/vim-signature/autoload/signature/utils.vim
039.016 000.985 000.872: sourcing
/home/dope/.vim/plugged/vim-signature/plugin/signature.vim
039.381 000.241 000.241: sourcing
/home/dope/.vim/plugged/vim-interestingwords/plugin/interestingwords.vim
039.643 000.147 000.147: sourcing
/home/dope/.vim/plugged/undotree/plugin/undotree.vim
039.852 000.080 000.080: sourcing
/home/dope/.vim/plugged/vim-plugin-AnsiEsc/plugin/AnsiEscPlugin.vim
040.185 000.305 000.305: sourcing
/home/dope/.vim/plugged/vim-plugin-AnsiEsc/plugin/cecutil.vim
040.734 000.164 000.164: sourcing
/home/dope/.vim/plugged/nerdtree/autoload/nerdtree.vim
041.327 000.350 000.350: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/path.vim
041.564 000.131 000.131: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/menu_controller.vim
041.840 000.110 000.110: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/menu_item.vim
042.060 000.123 000.123: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/key_map.vim
042.348 000.189 000.189: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/bookmark.vim
042.633 000.182 000.182: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/tree_file_node.vim
043.072 000.337 000.337: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/tree_dir_node.vim
043.329 000.156 000.156: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/opener.vim
043.629 000.192 000.192: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/creator.vim
043.809 000.071 000.071: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/flag_set.vim
044.046 000.130 000.130: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/nerdtree.vim
044.390 000.240 000.240: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/ui.vim
044.543 000.047 000.047: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/event.vim
044.721 000.065 000.065: sourcing
/home/dope/.vim/plugged/nerdtree/lib/nerdtree/notifier.vim
045.187 000.351 000.351: sourcing
/home/dope/.vim/plugged/nerdtree/autoload/nerdtree/ui_glue.vim
047.260 000.108 000.108: sourcing
/home/dope/.vim/plugged/nerdtree/nerdtree_plugin/exec_menuitem.vim
047.852 000.554 000.554: sourcing
/home/dope/.vim/plugged/nerdtree/nerdtree_plugin/fs_menu.vim
047.967 000.076 000.076: sourcing
/home/dope/.vim/plugged/nerdtree/nerdtree_plugin/vcs.vim
048.421 000.309 000.309: sourcing
/home/dope/.vim/plugged/vim-devicons/nerdtree_plugin/webdevicons.vim
048.572 008.214 004.329: sourcing
/home/dope/.vim/plugged/nerdtree/plugin/NERD_tree.vim
049.251 000.558 000.558: sourcing
/home/dope/.vim/plugged/vim-clang-format/plugin/clang_format.vim
049.528 000.158 000.158: sourcing
/home/dope/.vim/plugged/vim-illuminate/plugin/illuminate.vim
051.124 001.494 001.494: sourcing
/home/dope/.vim/plugged/vim-devicons/plugin/webdevicons.vim
051.356 000.099 000.099: sourcing
/home/dope/.vim/plugged/vim-minimap/plugin/minimap.vim
052.532 001.052 001.052: sourcing
/home/dope/.vim/plugged/vim-fugitive/plugin/fugitive.vim
053.067 000.407 000.407: sourcing
/home/dope/.vim/plugged/vim-surround/plugin/surround.vim
053.883 000.673 000.673: sourcing
/home/dope/.vim/plugged/quick-scope/plugin/quick_scope.vim
054.444 000.437 000.437: sourcing
/home/dope/.vim/plugged/taglist.vim/plugin/taglist.vim
056.638 001.696 001.696: sourcing
/home/dope/.vim/plugged/vcscommand.vim/plugin/vcscommand.vim
056.702 002.064 000.368: sourcing
/home/dope/.vim/plugged/vcscommand.vim/plugin/vcsbzr.vim
056.869 000.137 000.137: sourcing
/home/dope/.vim/plugged/vcscommand.vim/plugin/vcscommand.vim
057.828 000.930 000.930: sourcing
/home/dope/.vim/plugged/vcscommand.vim/plugin/vcscvs.vim
058.075 000.214 000.214: sourcing
/home/dope/.vim/plugged/vcscommand.vim/plugin/vcsgit.vim
058.233 000.127 000.127: sourcing
/home/dope/.vim/plugged/vcscommand.vim/plugin/vcshg.vim
058.386 000.124 000.124: sourcing
/home/dope/.vim/plugged/vcscommand.vim/plugin/vcssvk.vim
058.658 000.242 000.242: sourcing
/home/dope/.vim/plugged/vcscommand.vim/plugin/vcssvn.vim
059.119 000.324 000.324: sourcing
/home/dope/.vim/plugged/YouCompleteMe/plugin/youcompleteme.vim
059.533 000.282 000.282: sourcing
/home/dope/.vim/plugged/taboo.vim/plugin/taboo.vim
059.908 000.090 000.090: sourcing
/usr/local/share/vim/vim90/plugin/getscriptPlugin.vim
060.125 000.179 000.179: sourcing /usr/local/share/vim/vim90/plugin/gzip.vim
060.375 000.212 000.212: sourcing
/usr/local/share/vim/vim90/plugin/logiPat.vim
060.482 000.069 000.069: sourcing
/usr/local/share/vim/vim90/plugin/manpager.vim
060.708 000.189 000.189: sourcing
/usr/local/share/vim/vim90/plugin/matchparen.vim
061.187 000.441 000.441: sourcing
/usr/local/share/vim/vim90/plugin/netrwPlugin.vim
061.307 000.068 000.068: sourcing
/usr/local/share/vim/vim90/plugin/rrhelper.vim
061.412 000.060 000.060: sourcing
/usr/local/share/vim/vim90/plugin/spellfile.vim
061.662 000.179 000.179: sourcing
/usr/local/share/vim/vim90/plugin/tarPlugin.vim
061.842 000.136 000.136: sourcing /usr/local/share/vim/vim90/plugin/tohtml.vim
062.055 000.173 000.173: sourcing
/usr/local/share/vim/vim90/plugin/vimballPlugin.vim
062.283 000.180 000.180: sourcing
/usr/local/share/vim/vim90/plugin/zipPlugin.vim
062.289 004.023: loading plugins
062.341 000.052: loading packages
062.502 000.014 000.014: sourcing
/home/dope/.vim/plugged/vim-gtest/after/plugin/ctrlp.vim
062.586 000.037 000.037: sourcing
/home/dope/.vim/plugged/vim-gtest/after/plugin/fzf.vim
062.807 000.095 000.095: sourcing
/home/dope/.vim/plugged/vim-signature/after/plugin/signature.vim
062.836 000.349: loading after plugins
062.862 000.026: inits 3
063.597 000.735: reading viminfo
075.856 012.259: setup clipboard
075.885 000.029: setting raw mode
075.891 000.006: start termcap
075.927 000.036: clearing screen
077.614 001.687: opening buffers
078.178 000.329 000.329: sourcing
/home/dope/.vim/plugged/vim-signature/autoload/signature/sign.vim
078.911 000.225 000.225: sourcing
/home/dope/.vim/plugged/vim-signature/autoload/signature/mark.vim
084.348 001.792 001.792: sourcing
/home/dope/.vim/plugged/taglist.vim/plugin/taglist.vim
084.448 004.488: BufEnter autocommands
084.450 000.002: editing files in windows
085.745 000.760 000.760: sourcing
/home/dope/.vim/plugged/YouCompleteMe/autoload/youcompleteme.vim
149.701 064.491: VimEnter autocommands
149.706 000.005: before starting main loop
149.977 000.134 000.134: sourcing
/home/dope/.vim/plugged/vim-illuminate/autoload/illuminate.vim
150.472 000.056 000.056: sourcing
/home/dope/.vim/plugged/YouCompleteMe/autoload/youcompleteme/filetypes.vim
156.201 005.052 005.052: sourcing
/home/dope/.vim/plugged/vim-fugitive/autoload/fugitive.vim
157.011 000.250 000.250: sourcing
/home/dope/.vim/plugged/nerdfont.vim/autoload/nerdfont/path/extension.vim
157.019 000.441 000.191: sourcing
/home/dope/.vim/plugged/nerdfont.vim/autoload/nerdfont.vim
157.266 000.134 000.134: sourcing
/home/dope/.vim/plugged/nerdfont.vim/autoload/nerdfont/path/pattern.vim
157.663 000.120 000.120: sourcing
/home/dope/.vim/plugged/nerdfont.vim/autoload/nerdfont/path/basename.vim
157.905 000.097 000.097: sourcing
/home/dope/.vim/plugged/nerdfont.vim/autoload/nerdfont/fileformat.vim
158.616 002.876: first screen update
158.617 000.001: --- VIM STARTED ---

$ vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jul 9 2023 15:57:55)
Included patches: 1-1677
Compiled by dope@nl1lxd-111237
Huge version without GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm +tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
-balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
-browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand +perl +title
+channel +ipv6 +persistent_undo -toolbar
+cindent +job +popupwin +user_commands
+clientserver +jumplist +postscript +vartabs
+clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +vim9script
+cmdline_hist +langmap -python +viminfo
+cmdline_info +libcall +python3 +virtualedit
+comments +linebreak +quickfix +visual
+conceal +lispindent +reltime +visualextra
+cryptv +listcmds +rightleft +vreplace
+cscope +localmap +ruby +wildignore
+cursorbind +lua +scrollbind +wildmenu
+cursorshape +menu +signs +windows
+dialog_con +mksession +smartindent +writebackup
+diff +modify_fname +sodium +X11
+digraphs +mouse -sound +xfontset
-dnd -mouseshape +spell -xim
-ebcdic +mouse_dec +startuptime -xpm
+emacs_tags +mouse_gpm +statusline +xsmp_interact
+eval -mouse_jsbterm -sun_workshop +xterm_clipboard
+ex_extra +mouse_netterm +syntax -xterm_save
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: clang-15 -c -I. -Iproto -DHAVE_CONFIG_H -g -O2
-D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang-15 -Wl,-E -L/usr/local/lib -Wl,--as-needed -o vim -lSM
-lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lelf -lselinux
-lsodium -lacl -lattr -lgpm -L/usr/lib -llua5.2 -Wl,-E
-fstack-protector-strong -L/usr/local/lib
-L/usr/lib/x86_64-linux-gnu/perl/5.34/CORE -lperl -ldl -lm -lpthread
-lcrypt -L/usr/lib/python3.10/config-3.10-x86_64-linux-gnu
-lpython3.10 -lcrypt -ldl -lm -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6
-ldl -lz -lpthread -lm -lruby-3.0 -lm -L/usr/lib

Manas

unread,
Jul 16, 2023, 4:12:46 PM7/16/23
to vim...@googlegroups.com
On Sun, Jul 16, 2023 at 01:01:23PM -0700, Gary Johnson wrote:
> All of those things are possible and probably good ideas, but
> driving them all to zero would improve the time by only 656 ms and
> still leaves you with an annoying 2.1 s unaccounted for.
>
> The output of hyperfine shows only the program name. What command
> are you executing? If the command was something like this,
>
> vim -cq
>
> then I can't explain what vim could be doing from the time it
> printed "--- VIM STARTED ---" in the log until it exited.
>
> It would be interesting to see what hyperfine measures with the
> command
>
> vim -N -u NONE -i NONE -X -cq
>
I was using `hyperfine -i /usr/bin/vim`.

But I tested with above commands too.

```
$ hyperfine "vim -cq"
Benchmark 1: vim -cq
Time (mean ± σ): 2.414 s ± 0.017 s [User: 0.358 s, System: 0.048 s]
Range (min … max): 2.392 s … 2.447 s 10 runs


$ hyperfine "vim -N -u NONE -i NONE -X -cq"
Benchmark 1: vim -N -u NONE -i NONE -X -cq
Time (mean ± σ): 2.047 s ± 0.006 s [User: 0.032 s, System: 0.010 s]
Range (min … max): 2.039 s … 2.056 s 10 runs
```

--
Manas

Manas

unread,
Jul 16, 2023, 4:40:11 PM7/16/23
to vim...@googlegroups.com
On Sun, Jul 16, 2023 at 10:10:02PM +0200, Dominique Pellé wrote:
> In your startup file, I see:
>
> 374.858 001.193 001.193: sourcing
> /home/neon/.vim/plugged/vim-gutentags/autoload/gutentags.vim
> 377.927 002.447 002.447: sourcing
> /home/neon/.vim/plugged/YouCompleteMe/autoload/youcompleteme.vim
> 610.942 000.370 000.370: sourcing
> /home/neon/.vim/plugged/context.vim/autoload/context/line.vim
> 611.846 234.541: VimEnter autocommands
> 611.854 000.008: before starting main loop
>
> I don't understand how this works.
> Isn't it youcompleteme.vim which is slow? since the timestamp
> goes from 377.927ms to 610.942 ms.
Actually that confused me too. I reckon second column is the elapsed
time for that event. Maybe things are being initialized in parallel?

> In the original post, you said that startup took 2.6 sec but we see
> it's much faster than that from vim --startup.
>
> In my set up, youcompleteme.vim also seems to be the slowest step.
> But it's faster than for you.
I have a check in my youcompleteme configuration which helps me in
loading either ycm or coc.nvim for different filetypes.

```
let g:ycm_filetype_blacklist = {'rust': 1, 'erlang': 1, 'haskell': 1, \
'tablegen': 1, 'mlir': 1, 'svelte': 1, 'typescript':1}
```

Removing this check gives me a 38ms improvement (from 238ms to 200ms)
which is relatively a good amount.

But still yours is at 64ms and mine at 200ms. And IIRC I might have
built my ycm with all completers enabled. That may be the cause for it.

Rest of my ycm conf is straight taken up from their README page.

> Did you build with -O2? Consider posting the output of
> the `vim --version` command.
>
Here is my `vim --version`.


VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 04 2023 08:18:27)
Included patches: 1-1506
Compiled by Arch Linux
Huge version with GTK3 GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm +tcl/dyn
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
+balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
+browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand +perl/dyn +title
+channel +ipv6 +persistent_undo +toolbar
+cindent +job +popupwin +user_commands
+clientserver +jumplist +postscript +vartabs
+clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +vim9script
+cmdline_hist +langmap -python +viminfo
+cmdline_info +libcall +python3/dyn +virtualedit
+comments +linebreak +quickfix +visual
+conceal +lispindent +reltime +visualextra
+cryptv +listcmds +rightleft +vreplace
+cscope +localmap +ruby/dyn +wildignore
+cursorbind +lua/dyn +scrollbind +wildmenu
+cursorshape +menu +signs +windows
+dialog_con_gui +mksession +smartindent +writebackup
+diff +modify_fname -sodium +X11
+digraphs +mouse +sound -xfontset
+dnd +mouseshape +spell +xim
-ebcdic +mouse_dec +startuptime -xpm
+emacs_tags +mouse_gpm +statusline +xsmp_interact
+eval -mouse_jsbterm -sun_workshop +xterm_clipboard
+ex_extra +mouse_netterm +syntax -xterm_save
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/etc/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -pthread -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/vim/src=/usr/src/debug/vim -flto=auto -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.36/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -L/usr/local/lib -o vim -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lelf -lcanberra -lacl -lattr -lgpm -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.36/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -fstack-protector-strong -L/usr/local/lib -L/usr/lib/perl5/5.36/core_perl/CORE -lperl -lpthread -ldl -lm -lcrypt -lutil -lc -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lm

--
Manas

Gary Johnson

unread,
Jul 16, 2023, 4:49:29 PM7/16/23
to vim...@googlegroups.com
Interesting! That's crazy. It should not take nearly that long to
execute that last command. Vim is not doing anything but starting
without loading any files, then immediately exiting.

Is that what you observe without using hyperfine?

I've never used hyperfine; I've just read about it since your post.
I usually run a command with the time command, throw away the first
run because it includes the time time to fill caches, then average
the next three.

For example:

$ time vim -N -u NONE -i NONE -X -cq

real 0m0.030s
user 0m0.013s
sys 0m0.016s

What is the output of that command on your system?

I'm thinking that maybe we should try running vim under strace. Try
this and see what strace.out shows the running time to be.

$ strace -f -tt -o strace.out --summary vim -N -u NONE -i NONE -X -cq

The summary total time varies, but I get about 10 ms.

Regards,
Gary

Lifepillar

unread,
Jul 16, 2023, 5:05:53 PM7/16/23
to vim...@googlegroups.com
On 2023-07-16, Manas <manas...@iiitd.ac.in> wrote:
> `startuptime` surprisingly shows me a mere 656ms, while hyperfine shows
> me 2.7s. I am not sure how this discrepancy is arising. Here is the full
> log. https://pastebin.mozilla.org/uTrJ7i8N
>
> I see 234ms (out of those 656ms, ~35%) due to VimEnter autocommands.

170ms are also spent loading buffers. Do you need those to be loaded
eagerly at startup? Also, is context.vim for ConTeXt? ConTeXt support is
built-in into Vim (`:help ft-context`): do you need a plugin for that?
If so, why loading it at startup?

In general, if you see `autoload` paths in the output of --startuptime,
you should look further, because those are likely files that do not need
to be loaded at once.

You may shave some time off by avoiding loading built-in plugins that
you know you'll never use. In my vimrc, I disable some of those as
follows:

let g:loaded_getscriptPlugin = 1
let g:loaded_gzip = 1
let g:loaded_logiPat = 1
let g:loaded_rrhelper = 1
let g:loaded_tarPlugin = 1
let g:loaded_vimballPlugin = 1
let g:loaded_zipPlugin = 1

But your startup time is relatively high (mine is <60ms, an order of
magnitude less than yours, but still three times more than `vim
--clean`!), so I'd first act on the slowest parts. Certainly, you should
(and likely could) try to bring the number of autocommands close to
zero.

> My autocommands are just scattered throughout vimrc. Most of them are
> like:
>
> au FileType <list> [mappings|calls]
>
> Maybe there is a way to organize them better?

Put filetype-specific stuff under

~/.vim/after/

For instance, these are a few things you may put in
~/.vim/after/ftplugin/tex.vim for (La)TeX files:

" Local settings
setlocal conceallevel=0

" Filetype-specific mappings
nnoremap <silent><buffer> <leader>tp :<c-u>update<cr>:PdfLaTeX<cr>

" Filetype-specific commands
command! -buffer -nargs=? -complete=file PdfLaTeX call local#tex#typeset(<q-args>)

Anything that does not need to be immediately available when the
filetype is set goes into a corresponding autoload file. In the example
above, the typeset() function is needed only when the user executes
:PdfLateX. That function is then defined in a separate
~/.vim/autoload/local/tex.vim (I put my own stuff under a `local`
directory, but that's just my convention: any tree structure under
`autoload` will do).

Btw, this example is in legacy Vim script, but if you are starting
afresh I'd recommend using the new Vim 9 script syntax. See `:help
vim9`.

The same concept applies to your vimrc: anything that does not need to
be set at once when Vim starts should be turned into an autoload
function.

> And there are a ton of plugins too. Is there any way to only source them
> conditionally?

Yes. Put them under ~/.vim/pack/SOMEDIR/opt, where SOMEDIR is a name of
your choice. Then, use `packadd` to load them when necessary, either
manually or automatically. For instance, this is my Tagbar configuration
in my vimrc:

let g:tagbar_ctags_bin = '/opt/local/bin/uctags'
nnoremap <silent> <leader>vt :<c-u>silent call local#tagbar#toggle()<cr>

Then, the function that lazily loads the plugin and toggles the tag bar
is in ~/.vim/autoload/local/tagbar.vim:

fun! local#tagbar#toggle()
if !exists("g:loaded_tagbar")
packadd tagbar
endif
TagbarToggle
endf

You are using a plugin manager: I would also check whether the plugin
manager has a way to defer loading plugins.

> I can also try removing some of the old plugins. I haven't done a
> cleanup in a while.

That's a very good idea: as you become more comfortable with Vim, you
should review your plugins and get rid those that you are able to
replace with your own code (if you are willing to spend time on writing
your own stuff, of course) or with Vim built-in functionality.

For each plugin, ask you yourself:

- do I really need this? Maybe Vim already provides >90% of what the
plugin does, and I just need to learn Vim a bit better. I may live
without the remaining <10%, write my own code to fill the gap, or find
another plugin that covers just that 10%. Sites like
https://vim.fandom.com/wiki/Vim_Tips_Wiki may be helpful.
- Am I fully making use of this plugin? Sometimes, a plugin has
a hundred features, but I am using two or three. Maybe, I can
implement those two or three features myself?
- Is there an equivalent plugin that's less complex and possibly faster?
Fortunately, the Vim plugin ecosystem is vast. And the less popular
alternative is often as good or better than "what people is using".

Hope this helps,
Life.

Manas

unread,
Jul 16, 2023, 5:10:24 PM7/16/23
to vim...@googlegroups.com
On Sun, Jul 16, 2023 at 01:47:37PM -0700, Gary Johnson wrote:
> On 2023-07-17, Manas wrote:
> > I was using `hyperfine -i /usr/bin/vim`.
> >
> > But I tested with above commands too.
> >
> > ```
> > $ hyperfine "vim -cq"
> > Benchmark 1: vim -cq
> > Time (mean ± σ): 2.414 s ± 0.017 s [User: 0.358 s, System: 0.048 s]
> > Range (min … max): 2.392 s … 2.447 s 10 runs
> >
> >
> > $ hyperfine "vim -N -u NONE -i NONE -X -cq"
> > Benchmark 1: vim -N -u NONE -i NONE -X -cq
> > Time (mean ± σ): 2.047 s ± 0.006 s [User: 0.032 s, System: 0.010 s]
> > Range (min … max): 2.039 s … 2.056 s 10 runs
> > ```
>
> Interesting! That's crazy. It should not take nearly that long to
> execute that last command. Vim is not doing anything but starting
> without loading any files, then immediately exiting.
>
> Is that what you observe without using hyperfine?
I am starting to think this is some hyperfine issue. Because,

```
$ time vim -cq

real 0m0.396s
user 0m0.346s
sys 0m0.047s

$ time vim -N -u NONE -i NONE -X -cq

real 0m0.035s
user 0m0.022s
sys 0m0.013s
```

> I've never used hyperfine; I've just read about it since your post.
> I usually run a command with the time command, throw away the first
> run because it includes the time time to fill caches, then average
> the next three.
>
> For example:
>
> $ time vim -N -u NONE -i NONE -X -cq
>
> real 0m0.030s
> user 0m0.013s
> sys 0m0.016s
>
> What is the output of that command on your system?
>
> I'm thinking that maybe we should try running vim under strace. Try
> this and see what strace.out shows the running time to be.
>
> $ strace -f -tt -o strace.out --summary vim -N -u NONE -i NONE -X -cq
>
> The summary total time varies, but I get about 10 ms.
>
I am also getting 10ms. Here is the detailed log.
https://pastebin.mozilla.org/1PU0phce

--
Manas

Manas

unread,
Jul 16, 2023, 5:20:26 PM7/16/23
to vim...@googlegroups.com
On Sun, Jul 16, 2023 at 09:05:37PM -0000, Lifepillar wrote:
> 170ms are also spent loading buffers. Do you need those to be loaded
> eagerly at startup? Also, is context.vim for ConTeXt? ConTeXt support is
> built-in into Vim (`:help ft-context`): do you need a plugin for that?
> If so, why loading it at startup?
No it is different. [context.vim](https://github.com/wellle/context.vim)

I have found it quite useful for large codebases.
These are really phenomenal tips. Thanks a lot, Life. I am refactoring
the plugins now. I hope to make things under 100ms.

--
Manas

rwmit...@gmail.com

unread,
Jul 16, 2023, 6:28:25 PM7/16/23
to vim_use
How often are you starting vim?

The great thing about current OSes vs those of the 30+ years ago, you can have multiple terminals and apps open at one time.  When working on code, I keep a vim session up the entire time with the files I'm editing loaded and just switch terminals to compile and test. A mouse (trackpad) flick takes little time.

Dominique Pellé

unread,
Jul 16, 2023, 7:01:58 PM7/16/23
to vim...@googlegroups.com
Manas <manas...@iiitd.ac.in> wrote:

> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -pthread -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/vim/src=/usr/src/debug/vim -flto=auto -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
> Linking: gcc -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.36/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -L/usr/local/lib -o vim -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lelf -lcanberra -lacl -lattr -lgpm -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.36/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -fstack-protector-strong -L/usr/local/lib -L/usr/lib/perl5/5.36/core_perl/CORE -lperl -lpthread -ldl -lm -lcrypt -lutil -lc -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lm

I see you use:
* for compilation: -flto=auto ... -O2 (actually also -O1 but last one
overrides)
* for linking: -Wl,-O1 -flto=auto

I'm not 100% sure, but since you use LTO (Link Time Optimization),
the compilation happens at link time, so I suppose that -O1 is used
instead of -O2. Try to make sure that -Wl,-O2 is also used at link
time if you use LTO, it may help to speed up Vim significantly.

Dominique

Manas

unread,
Jul 17, 2023, 4:53:31 AM7/17/23
to vim...@googlegroups.com
I did two fresh builds,

1. CFLAGS=-O2 -flto=auto; LDFLAGS=-Wl,-O2 -flto=auto
2. Default: CFLAGS=-O2; LDFLAGS=<no-optimizations>

and I didn't find any significant different in startuptimes.

# Benchmarks

1. With LTO and -O2
```
$ hyperfine -w 5 "./vim.lto -N -u NONE -i NONE -X -cq"
Benchmark 1: ./vim.lto -N -u NONE -i NONE -X -cq
Time (mean ± σ): 2.028 s ± 0.004 s [User: 0.012 s, System: 0.010 s]
Range (min … max): 2.024 s … 2.035 s 10 runs


$ time ./vim.lto -u NONE -i NONE -X -cq

real 0m0.021s
user 0m0.011s
sys 0m0.010s
```

2. Without LTO and -O2 (at compile-time)

```
$ hyperfine -w 5 "./vim -N -u NONE -i NONE -X -cq"
Benchmark 1: ./vim -N -u NONE -i NONE -X -cq
Time (mean ± σ): 2.030 s ± 0.009 s [User: 0.011 s, System: 0.011 s]
Range (min … max): 2.023 s … 2.052 s 10 runs


$ time ./vim -u NONE -i NONE -X -cq

real 0m0.024s
user 0m0.010s
sys 0m0.014s
```

--
Manas

Manas

unread,
Jul 17, 2023, 5:02:36 AM7/17/23
to vim...@googlegroups.com
On Sun, Jul 16, 2023 at 03:28:25PM -0700, rwmit...@gmail.com wrote:
> How often are you starting vim?
>
> The great thing about current OSes vs those of the 30+ years ago, you can
> have multiple terminals and apps open at one time. When working on code, I
> keep a vim session up the entire time with the files I'm editing loaded and
> just switch terminals to compile and test. A mouse (trackpad) flick takes
> little time.
>
I do use tmux but I prefer to have different vim sessions for different
projects. Movement, management and saving things around in tmux is quite
helpful than putting every project in 1 vim session. And I really can't
afford to keep all those sessions opened at all times too. 3 instances
of rust-analyzer(or any lsp for that matter) for 3 large codebases and
my ram starts crying.

--
Manas

Christian Brabandt

unread,
Jul 17, 2023, 6:07:05 AM7/17/23
to vim...@googlegroups.com

On So, 16 Jul 2023, Gary Johnson wrote:

> On 2023-07-17, Manas wrote:
> > $ hyperfine "vim -N -u NONE -i NONE -X -cq"
> > Benchmark 1: vim -N -u NONE -i NONE -X -cq
> > Time (mean ± σ): 2.047 s ± 0.006 s [User: 0.032 s, System: 0.010 s]
> > Range (min … max): 2.039 s … 2.056 s 10 runs
>
> Interesting! That's crazy. It should not take nearly that long to
> execute that last command. Vim is not doing anything but starting
> without loading any files, then immediately exiting.
>
> Is that what you observe without using hyperfine?
>
> I've never used hyperfine; I've just read about it since your post.
> I usually run a command with the time command, throw away the first
> run because it includes the time time to fill caches, then average
> the next three.

I have never heard about hyperfine¹ before, but it always seems to spawn
a new shell and even so it is supposed to correct the shell spawning
time, perhaps there is something going wrong? I would try using `-N` to
disable the intermediate shell and probably open a new ticket about
this.

¹https://github.com/sharkdp/hyperfine

Best,
Christian
--
Leute, die immer nur mitfahren, sind stolz darauf, keine Unfälle zu
verschulden.
-- Gabriel Laub

Christian Brabandt

unread,
Jul 17, 2023, 6:08:54 AM7/17/23
to vim...@googlegroups.com

On Mo, 17 Jul 2023, Manas wrote:

> $ time vim -cq
>
> real 0m0.396s
> user 0m0.346s
> sys 0m0.047s

So now that you are at .3s startup time, is this okay or not?

Best
Christian
--
Kleine Seelen fühlen in ihrem Unglück nur ihren Zustand, große noch
Zusammenhang, ihr Ich.
-- Jean Paul

Christian Brabandt

unread,
Jul 17, 2023, 6:10:36 AM7/17/23
to vim...@googlegroups.com

On Mo, 17 Jul 2023, Manas wrote:

> `startuptime` surprisingly shows me a mere 656ms, while hyperfine shows
> me 2.7s. I am not sure how this discrepancy is arising. Here is the full
> log. https://pastebin.mozilla.org/uTrJ7i8N

HTTP 404 Snippet not found

Best,
Christian
--
Dem Alltagsstreß kannst Du entgeh'n.
wenn Du vermeidest aufzusteh'n.

Manas

unread,
Jul 17, 2023, 6:42:18 AM7/17/23
to vim...@googlegroups.com
On Mon, Jul 17, 2023 at 12:06:55PM +0200, Christian Brabandt wrote:
> I have never heard about hyperfineน before, but it always seems to spawn
> a new shell and even so it is supposed to correct the shell spawning
> time, perhaps there is something going wrong? I would try using `-N` to
> disable the intermediate shell and probably open a new ticket about
> this.
>
Not spawing shell doesn't help either. Anyways I have filed a ticket.
https://github.com/sharkdp/hyperfine/issues/666

Also, previous logs are expired so I re-created those logs and put them
on gist.[1][2]

[1] startuptime: https://gist.github.com/weirdsmiley/19cc04445f8b0a37206b98de53e58339
[2] strace.out: https://gist.github.com/weirdsmiley/8a0f70efa7bf93d69181c7bf03e3a2bb

--
Manas

Manas

unread,
Jul 17, 2023, 6:43:20 AM7/17/23
to vim...@googlegroups.com
On Mon, Jul 17, 2023 at 12:08:46PM +0200, Christian Brabandt wrote:
>
> On Mo, 17 Jul 2023, Manas wrote:
>
> > $ time vim -cq
> >
> > real 0m0.396s
> > user 0m0.346s
> > sys 0m0.047s
>
> So now that you are at .3s startup time, is this okay or not?
It is okay but I am doing refactoring nonetheless.

--
Manas

jr

unread,
Jul 17, 2023, 9:41:12 AM7/17/23
to vim...@googlegroups.com
hi,

On Sun, 16 Jul 2023 at 21:40, Manas <manas...@iiitd.ac.in> wrote:
> ...
> But still yours is at 64ms and mine at 200ms. ...
> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -pthread -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/vim/src=/usr/src/debug/vim -flto=auto -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1

long shot. I have noticed (or so I think, never sat down to .. time
things :-)) that programs appear to start up a little faster when
compiled with the '-fPIC' flag ? (may, of course, be just an artefact
of the machine's configuration)

--
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')

this email is intended only for the addressee(s) and may contain
confidential information. if you are not the intended recipient, you
are hereby notified that any use of this email, its dissemination,
distribution, and/or copying without prior written consent is
prohibited.

Dominique Pellé

unread,
Jul 17, 2023, 11:07:49 AM7/17/23
to vim...@googlegroups.com
Manas <manas...@iiitd.ac.in> wrote:

> > > $ time vim -cq
> > >
> > > real 0m0.396s
> > > user 0m0.346s
> > > sys 0m0.047s

It seems a bit slow.

For me on xubuntu-22.04 (i7-8700K):
$ time vim -cq

real 0m0.129s
user 0m0.106s
sys 0m0.023s

and on macOS-13.4.1 (M1):
$ time vim -cq

real 0m0.109s
user 0m0.071s
sys 0m0.022s

Manas

unread,
Jul 17, 2023, 2:19:18 PM7/17/23
to vim...@googlegroups.com
That might be due to different versions/features enabled. I am using
pacman's package. I posted my complete version in a previous post.

Also, David (hyperfine creator ig) found the missing 2s.
https://github.com/vim/vim/blob/4c0089d696b8d1d5dc40568f25ea5738fa5bbffb/src/main.c#L2802-L2807

Passing `/dev/null` as script file doesn't halt the execution and
instantly shows the actual startuptime.

```bash
$ hyperfine "vim -N -u NONE -i NONE -X -cq -s /dev/null"
Benchmark 1: vim -N -u NONE -i NONE -X -cq -s /dev/null
Time (mean ± σ): 36.0 ms ± 4.5 ms [User: 23.6 ms, System: 11.8 ms]
Range (min … max): 30.9 ms … 49.7 ms 79 runs
```

--
Manas

Christian Brabandt

unread,
Jul 17, 2023, 2:24:08 PM7/17/23
to vim...@googlegroups.com

On Mo, 17 Jul 2023, Manas wrote:

> Also, David (hyperfine creator ig) found the missing 2s.
> https://github.com/vim/vim/blob/4c0089d696b8d1d5dc40568f25ea5738fa5bbffb/src/main.c#L2802-L2807
>
> Passing `/dev/null` as script file doesn't halt the execution and
> instantly shows the actual startuptime.

You can also use `--not-a-term` IIRC.

Best,
Christian
--
In Rücksicht der Geschlechtsünden scheint auch der offenste Mensch ein
Heuchler zu sein; aber bloß weil er verbirgt, was alle verbergen,
sogar das Erlaubte, und weil jeder weniger sinnlich scheinen muß, als
er ist.
-- Jean Paul
Reply all
Reply to author
Forward
0 new messages