slow
dylnmc opened this issue · comments
mundo used to be the fastest.
now:
- at work (windows + gvim), it takes mundo well over 1 minute to open up
- at home (archlinux + vim), mundo takes a few seconds to open and it makes my cpu go crazy and it blocks up when I press
jjjjjeven just like 4-5 times.
something bad happened. roll back or something. maybe it's just me, but it's affecting all of my vim sessinos on all the machines I use.
@dylnmc sorry to heard about this! Can you post what versions you're using? I unfortunately don't have ready access to a windows box, but I can at least look into the arch side.
At the time of this writing: it was whatever version was on github, as I was and am using vim-plug
currently: @ work -> will check again when I get home if it is fast enough on arch linux
Oh I'm sorry I meant what version of vim are you using?
at work:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Apr 23 2017 20:01:28)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-586
Compiled by mool@tororo
Huge version with GUI. Features included (+) or not (-):
+acl +eval +mouse +syntax
+arabic +ex_extra +mouseshape +tag_binary
+autocmd +extra_search +multi_byte_ime/dyn +tag_old_static
+balloon_eval +farsi +multi_lang -tag_any_white
+browse +file_in_path -mzscheme +tcl/dyn
++builtin_terms +find_in_path +netbeans_intg -termguicolors
+byte_offset +float +num64 -tgetent
+channel +folding +ole -termresponse
+cindent -footer +packages +textobjects
+clientserver +gettext/dyn +path_extra +timers
+clipboard -hangul_input +perl/dyn +title
+cmdline_compl +iconv/dyn +persistent_undo +toolbar
+cmdline_hist +insert_expand -postscript +user_commands
+cmdline_info +job +printer +vertsplit
+comments +jumplist +profile +virtualedit
+conceal +keymap +python/dyn +visual
+cryptv +lambda +python3/dyn +visualextra
+cscope +langmap +quickfix +viminfo
+cursorbind +libcall +reltime +vreplace
+cursorshape +linebreak +rightleft +wildignore
+dialog_con_gui +lispindent +ruby/dyn +wildmenu
+diff +listcmds +scrollbind +windows
+digraphs +localmap +signs +writebackup
+directx -lua +smartindent -xfontset
-dnd +menu +startuptime -xim
-ebcdic +mksession +statusline +xpm_w32
+emacs_tags +modify_fname -sun_workshop -xterm_save
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$HOME\vimfiles\vimrc"
3rd user vimrc file: "$VIM\_vimrc"
user exrc file: "$HOME\_exrc"
2nd user exrc file: "$VIM\_exrc"
system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$HOME\vimfiles\gvimrc"
3rd user gvimrc file: "$VIM\_gvimrc"
defaults file: "$VIMRUNTIME\defaults.vim"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_XPM_W32 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 /Fo.\ObjGXOLYHTRi386/ /Ox /GL -DNDEBUG /Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL -DDYNAMIC_TCL_DLL=\"tcl86.dll\" -DDYNAMIC_TCL_VER=\"8.6\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python35.dll\" -DFEAT_PERL -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl524.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=22 -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby220.dll\" -DFEAT_HUGE /Fd.\ObjGXOLYHTRi386/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.lib /machine:i386 gdi32.lib version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib /machine:i386 /nodefaultlib libcmt.lib oleaut32.lib user32.lib /nodefaultlib:python27.lib /nodefaultlib:python35.lib "E:\tcl\lib\tclstub86.lib" WSock32.lib xpm\x86\lib\libXpm.lib /PDB:gvim.pdb -debug
at home: the newest version from github update ~weekly.
by the way: the plugin seems faster now on my windows machine. I am afraid that what I was experiencing might not be that replicable (it seemed to happen only on files that I had been working on for a while and that had a lot of changes in them, but I can't be certain).
edit: it's definitely way faster. let me check out on arch @ home, then I will close if seems to be resolved. I was using UndoTree (well, I only really use tree visualizers a little, anyway), but maybe if it keeps being fast, then I'll switch back.
I promise I wasn't just making up the slowness (it was particularly slow on windows), but it doesn't seem to be an issue right now on any of my machines. I think there was one or two updates in the meantime, but I don't even know if it was mundo's fault.
cheers,
Thanks anyway - your double checking is appreciated!
I hate to reopen the issue, and while I love mundo, it is very nonperformant in my (fairly up-to-date) 32-bit version of gvim.exe on windows 10.
I am not sure if this does happen - for I have not looked at the code - but it seems like mundo generates data for searching capabilities that other undo tree visualisation plugins lack, and this seems to take a long time on windows (while it may be performant on UNIX and its variants).
I would like to use mundo, but I fear opening it because when I have more than 50 changes, it can take over 10 seconds to open. If I have hundreds of changes, it can take over half a minute to open.
Note that this only happens the first time when opening mundo - so that should help you narrow down what is causing the slowness.
I believe I saw you mention somehwere that windows has not been tested thouroughly, and I don't necessarily expect you, the maintainer, to test on windows if you really do not want to, but if someone else can test on windows and notices the same thing, then a patch would be very welcome and would help me out a lot!
Thanks,
Dylan
I started noticing major lag with undo operations when syntax is enabled. If you do :syn off first then :MundoToggle it works much better. Perhaps this could be incorporated into the plugin (in particular for windows but potentially for linux as well, since it can only improve the performance) maybe by noting the b:&syntax or w:&syntax variable, setting it to empty then setting it back after opening mundo. For now, I will just put it in the actual mapping I have (<leader>u).
Thanks
In order to temporarily fix the issue, I had to go through quite a few hoops, since some functions (the ones checking if mundo is open) are not exposed:
" toggle mundo tree
function! s:mundoToggle()
let cwin = -1
let syn = ''
let synflag = 0
if buffer_name('%') !~# '^__Mundo\%(_Preview\)\?__$'
let synflag = 1
let cwin = win_getid()
let syn = &syntax
setlocal syntax=
endif
MundoToggle
if synflag
let winflag = cwin !=# -1 && buffer_name('%') =~# '^__Mundo\%(_Preview\)\?__$'
if winflag
call win_gotoid(cwin)
endif
execute 'setlocal syntax='.syn
if winflag
wincmd p
endif
endif
endfunction
nnoremap <leader>u :call <sid>mundoToggle()<cr>
I'm experiencing the same slow behavior in big files with a lot of persistent history (like 2 to 3 minutes to open mundo the first time), if I do syntax off before opening mundo, it opens instantly.
Edit: The syntax off trick, only needs to happen the first time mundo is opened for the current file, after the first time, mundo opens fast even with syntax on.
Edit 2: Sorry, I'm on Neovim at HEAD in a Linux terminal (Alacritty).