Bufexplorer is slow when lots of buffers open

[Uroc327]

When I start vim with multiple files, bufexplorer is perfectly fast.

When I've opened lots of files, then bufexplorer gets slower and slower until it's really hard to select the correct file as bufexplorer reacts extremely slow.

[jlanzarotta]

Hello,

Well heck, that is not good. How many files do you have open at one time?

[Uroc327]

I have some projects with 100-200 files.. But this doesn't affect bufexplorer speed at all.

It slows down as I open more and more files. At round about 15 opened files (marked blue instead of green) it is possible to notice some lag, but it's not critical yet. With round about 20 files it gets remarkably slower, forcing the user to take the lag into account when trying to navigate to a file per keyboard. Also bufexplorer starts to need some time to open and close itself and switch from or to a buffer.

Approaching 50 opened files, bufexplorer begins to become unusable when trying to hold down the up/down key to move more than one entry up or down.

[jlanzarotta]

Yikes! I wonder what the heck is going on. Are you on Windows?

[Uroc327]

Nope I'm on Arch Linux
My vim config is

$ gvim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 11 2014 03:20:17)
Included patches: 1-473
Compiled by Arch Linux
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
+balloon_eval    +float           +mouse_urxvt     -tag_any_white
+browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
+clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      +toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  +lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      +X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
+emacs_tags      +mouseshape      -sniff           +xsmp_interact
+eval            +mouse_dec       +startuptime     +xterm_clipboard
+ex_extra        +mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   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"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz  -D_FORTIFY_SOURCE=2  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE  -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype  -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm -lncurses -lelf -lnsl   -lacl -lattr -lgpm -ldl  -L/usr/lib -llua -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -L/usr/local/lib  -L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic   -lruby -lpthread -lgmp -ldl -lcrypt -lm  -L/usr/lib   

My bufexplorer settings are

let g:bufExplorerDisableDefaultKeyMapping=1
let g:bufExplorerFindActive=0
let g:bufExplorerShowNoName=1
let g:bufExplorerSortBy='fullpath'
map <silent> <F2> :BufExplorer<CR>

I have installed round about 30 plugins, could it be possible that bufexplorer interferes with some other kind of plugin (syntax or other stuff)?

[jlanzarotta]

Hum, this is interesting... and definitely an issue.

I opened around 30 files and when I open bufexplorer and press 'm' (which shows the MRU list) I have way to many items in the MRU list. I am thinking it has to do with unlisted buffers...

[Uroc327]

Hmm... with ~50 files (running slow ofc) I have a mru list with round about 60-70 elements, with each file opened exactly once (no buffer switching back and forth, just opening 50 files one after another)

[Uroc327]

Just noticed something: argdo doesn't have any effect on bufexplorers speed, although it opens every buffer of course.

The reason for this slowness does not seem to be how many buffers I've opened, but how often I've switched buffers.

[Uroc327]

According to a vim profile these lines are the 'worst'

function          count  total (s)   self (s)     line
BufExplorer          55   3.951864   0.012892     silent let s:raw_buffer_listing = s:GetBufferInfo(0)
BufExplorer          55   1.140781   0.000395     call s:DisplayBufferList()
SelectBuffer         53  18.745413   0.062483             execute "keepalt keepjumps silent b!" _bufNbr
DisplayBufferList    55   1.089410   0.001018     call s:BuildBufferList()
GetBufferInfo     51695   0.724796   0.506957             call add(allwidths[n], s:StringWidth(b[n]))
GetBufferInfo     51430   0.729095   0.515161                 call add(listedwidths[n], s:StringWidth(b[n]))

[ghost]

I'm experiencing this as well.

[jlanzarotta]

Sorry, I have not come up with a solution on this yet...

[ghost]

I think I solved it on my fork, you can check it out. I've been using it
for more than a month I think.

On 02/04/2016 04:32 PM, jlanzarotta wrote:

Sorry, I have not come up with a solution on this yet...

—
Reply to this email directly or view it on GitHub
#21 (comment).

[johndgiese]

I'm also experiencing this slowdown.

[ghost]

I think I fixed it on my fork, check it out to see if that fixes it. I
told the maintainer about it as well but he doesn't seem interested or
doesn't like the fix.

On 03/02/2016 11:26 PM, David Giese wrote:

I'm also experiencing this slowdown.

—
Reply to this email directly or view it on GitHub
#21 (comment).

[jlanzarotta]

Hi,
Sorry about that. I did not see your comment until just now as I was going through some old emails... I will take a look at your fix hopefully today and get back with you...

[jlanzarotta]

Looks like a reasonable patch. Just two line changed. I have made the change locally and will give it a try over the next few days and report back.

Thanks again for the patch and sorry for the delay in responding back.

[jlanzarotta]

So far so good on the patch. I hope to have a new version submitted this week.

[ghost]

@jlanzarotta Thanks for mentioning me in the patch. This issue can be closed now, right?

[jlanzarotta]

yeap, it can be closed... I am still not used to github :)

[Uroc327]

Hmm.. Sorry for being quiet the last few months, but the issue does not seem fixed to me :/
I still experience the same problem as stated in the first post.