very slow start time?

+ 178 533.658  000.209  000.209: sourcing /home/dmitry/.vim/bundle/vim-pyenv/autoload/pyenv.vim
+ 179 534.944  000.042  000.042: sourcing /home/dmitry/.vim/bundle/vim-easymotion/autoload/vital.vim
+ 180 537.230  000.591  000.591: sourcing /home/dmitry/.vim/bundle/vim-pyenv/autoload/vital/_vim_pyenv.vim
+ 181 540.863  006.266  005.633: sourcing /home/dmitry/.vim/bundle/vim-pyenv/autoload/pyenv/utils.vim                  
+ 182 546.029  000.381  000.381: sourcing /home/dmitry/.vim/bundle/vim-pyenv/autoload/vital/_vim_pyenv/Process.vim
+ 183 551.353  000.449  000.449: sourcing /home/dmitry/.vim/bundle/vim-pyenv/autoload/vital/_vim_pyenv/System/Filepath.
+ 184 555.364  021.249  014.153: sourcing /home/dmitry/.vim/bundle/vim-pyenv/autoload/pyenv/pyenv.vim
+ 185 561.908  005.842  005.842: sourcing /home/dmitry/.vim/bundle/vim-pyenv/autoload/pyenv/python.vim
+ 186 1363.001  001.016  001.016: sourcing /home/dmitry/.vim/bundle/vim-gutentags/autoload/gutentags.vim

so 533 > 1363 almost a second. It makes switching to vim (from ipython session with F2 for example) very very slow

ANy ideas?

Start with the Vim startup profile in the issue and inspect the listed vim-pyenv entry points, especially autoload/pyenv/pyenv.vim and autoload/pyenv/python.vim. Compare their sourcing times with autoload/gutentags/autoload/gutentags.vim and determine which startup step accounts for the delay. Done means the slow source is identified and a focused fix or documented explanation is available.