vimade causes vim processes to use 250MB+ of memory

[bitwombat]

With vimade as my only plugin, I'm finding vim processes go from a startup RSS size of ~30MB to 250MB+ in a few hours.

Not sure how to debug beyond isolating it, but happy to help.

Vim 8.0.1453, Ubuntu 18.04 LTS system.

[TaDaa]

I'll have to take a look later, is your vimrc / config available? If not if you can copy paste the minimal version that is showing issues here that would work. Also are you running in terminal and if so which one/version?

[bitwombat]

Running in xterm v330

For this test, my .vimrc is just:

call pathogen#infect()
colorscheme zenburn

set nocompatible
set hidden
set laststatus=2
set modeline
set ruler
set showcmd
set showmatch
set noshowmode
set cursorline
set t_ut=
set fileformat=unix
set scrolloff=2
set vb t_vb=
set wildmenu

filetype on
syntax on

[TaDaa]

So far I've been unable to reproduce this, but I'll keep playing with it later. Perhaps something is causing matches or timers to leak -- most of vimade's caching/work is done within python so I wouldn't expect to see the vim process affected that much. May be worth trying:

let g:vimade={}
let g:vimade.usecursorhold=1

and see if the memory usage is reduced.

Are there any other plugins in your ~/.vim/bundle folder or where pathogen is set or Is it just vimade and zenburn? Also is there anything special about the files you are working with (large in size, contain control characters, non-utf8)

[bitwombat]

Bugger that it's not showing up. I'll try your two settings. No, no other plugins - this was an empty .vim and the .vimrc just as shown above. And plain text files as far as I can tell. I'll save the session (I think this is a good way to show all settings?)

[bitwombat]

Results: With the two g:vimade variables set as you instructed above, memory does not grow.

Here's the vim session from when memory does grow. Session.vim.txt

If it's of use, memory growth looks like this. The vim session has two windows, with one 6-line text file, and one new buffer.

(i) (master)[~]$ echo -n "$(date) / " && ps -eo size,rss,command  | grep -E '[0-9] vim /prj'
Tue  2 Jun 11:11:01 AEST 2020 / 23020 43692 vim /prj/vim_memory_leak.md
Tue  2 Jun 11:28:10 AEST 2020 / 26540 47116 vim /prj/vim_memory_leak.md
Tue  2 Jun 11:29:07 AEST 2020 / 26796 47372 vim /prj/vim_memory_leak.md

Maybe of interest, with the g:vimade variables set, it starts out at roughly 10MB lighter. Seems like a lot?

Tue  2 Jun 11:32:11 AEST 2020 / 10076 26576 vim /prj/vim_memory_leak.md

[TaDaa]

Thanks yeah -- was able to reproduce something similar by reducing the timer phase to 1 -- seeing that vim.eval seems to have a pretty large leak. Seems like its a general issue, but want to see if I can reproduce it in a minimal script later. Neovim seems unaffected by this issue.

I think I can work around it by replacing the vim.evals with vim.command+vim.vars, but I'll need to make sure that performance isn't impacted and that I can correctly account for the type differences (its much simpler to work with vim.eval) and that it works in python2 and python3.

[TaDaa]

Think these changes should lessen the memory build-up without using usecursorhold. Let me know if they resolve the issue for you.

[bitwombat]

That fixed the problem - no more 250MB vim processes!