Re: Vim memory leak
On 4/3/07, Max Dyckhoff [EMAIL PROTECTED] wrote: My instance of vim (gvim on Windows) appears to have a memory leak, which makes me sad. Is this a common thing for everyone, or is there something in my setup which might be causing it? It's pretty serious. When I start gvim and load my standard session, it will take up about 86MB of RAM. This includes dozens of buffers, splits, tabs and syntax, so I'm not really worried. After about four hours it will be up to more like 120MB, and after a couple of days it will be 200MB+. Loading a fresh copy of gvim with all the plugins and my .vimrc, there are various actions I can see that increase the memory usage as reported by the Windows Task Manager. I have no idea on the validity of the Task Manager, but it's all I have on Windows. :sp on a new buffer causes a raise of 4-8K. :q on a split causes a raise of 4-8K. Switching to/from gvim causes a small increase, typically 4-8K for a few switches. Searching (with *) for a word in a .c file (with syntax highlighting) causes it to increase. If you hold down * then you can see the memory usage rocket up. Basically, pretty much any action. Any ideas? Will I just have to live with it and restart my vim session every couple of days? Did you try to set the 'maxmemtot' option ? (:help 'maxmemtot') Does memory drop down if you :bw all buffers ? If you could simulate thousands of user actions using ClientServer using some action-simulating script and have vim grow past 400-500 mb that would be demonstration. It is not easy to distinguish necessary grow from memory leak. But my firefox will predictably grow above 200mb in just couple of days in th air. And it does not have memory leak for all I know. But if you can cause it grow indefinitely by opening and closing some page, that would establish a memory leak. Maybe you simply need to buy anoth 1GB of RAM ? This sharply reduces feelings from another 200gb process :-) Yakov
Re: Vim memory leak
On 4/4/07, Max Dyckhoff [EMAIL PROTECTED] wrote: My instance of vim (gvim on Windows) appears to have a memory leak, which makes me sad. Is this a common thing for everyone, or is there something in my setup which might be causing it? It's pretty serious. When I start gvim and load my standard session, it will take up about 86MB of RAM. This includes dozens of buffers, splits, tabs and syntax, so I'm not really worried. After about four hours it will be up to more like 120MB, and after a couple of days it will be 200MB+. Loading a fresh copy of gvim with all the plugins and my .vimrc, there are various actions I can see that increase the memory usage as reported by the Windows Task Manager. I have no idea on the validity of the Task Manager, but it's all I have on Windows. :sp on a new buffer causes a raise of 4-8K. :q on a split causes a raise of 4-8K. Switching to/from gvim causes a small increase, typically 4-8K for a few switches. Searching (with *) for a word in a .c file (with syntax highlighting) causes it to increase. If you hold down * then you can see the memory usage rocket up. Basically, pretty much any action. Any ideas? Will I just have to live with it and restart my vim session every couple of days? Max, I recalled two more things. Is your 'hidden' option set ? If it's set, vim *will* grow. With 'hidden' set, vim will keep in memory much data about old buffers. If you want to minimize memory, first thing you'd do is ':set nohidden'. To check your current state, 'set hidden?'. Second important thing is :bw. Even with ':set nohidden', vim will remember some data for every file it ever visited. To free this data completely, you need to :ls!, then :bw for every unused buffer. I think these two things will decrease vim's memory footprint (in case you had 'set hidden'). Yakov
RE: Vim memory leak
On 4/4/07, Yakov Lerner [EMAIL PROTECTED] wrote: Max, I recalled two more things. Is your 'hidden' option set ? If it's set, vim *will* grow. With 'hidden' set, vim will keep in memory much data about old buffers. If you want to minimize memory, first thing you'd do is ':set nohidden'. To check your current state, 'set hidden?'. Second important thing is :bw. Even with ':set nohidden', vim will remember some data for every file it ever visited. To free this data completely, you need to :ls!, then :bw for every unused buffer. I think these two things will decrease vim's memory footprint (in case you had 'set hidden'). Yakov I do have 'hidden' set, because I like to keep things around. :ls! shows that I currently have about 550 buffers open. I know this seems like a lot, but we do have a large code base! The thing is that if I open this session then it takes up about 90Mb, which is fine for me. But after a few hours and modifications to only a handful of buffers, this has grown to 130Mb or so, which seems excessive. Is there any way I can limit the number of 'hidden' buffers? It'd be nice if it had a history much like : and /, where the least recently used things fall off the bottom (top?). I'm sure that I could manage with only about 100 hidden buffers. Failing that, do you think it could be done in script? Do something like get an array of all the files, check the last touched time, and then discard the oldest? Also, starting up with -u NONE does indeed still exhibit the same memory leakage (or use), although it seems a bit slower. Thanks, Max
Re: Vim memory leak
On 4/4/07, Max Dyckhoff [EMAIL PROTECTED] wrote: On 4/4/07, Yakov Lerner [EMAIL PROTECTED] wrote: Max, I recalled two more things. Is your 'hidden' option set ? If it's set, vim *will* grow. With 'hidden' set, vim will keep in memory much data about old buffers. If you want to minimize memory, first thing you'd do is ':set nohidden'. To check your current state, 'set hidden?'. Second important thing is :bw. Even with ':set nohidden', vim will remember some data for every file it ever visited. To free this data completely, you need to :ls!, then :bw for every unused buffer. I think these two things will decrease vim's memory footprint (in case you had 'set hidden'). Yakov I do have 'hidden' set, because I like to keep things around. :ls! shows that I currently have about 550 buffers open. ... we do have a large code base! Then get another 1-2 GB of RAM. It's not called memory leak when program allocates memory according to its functionality. Yakov
RE: Vim memory leak
On 4/4/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 4/4/07, Max Dyckhoff [EMAIL PROTECTED] wrote: I do have 'hidden' set, because I like to keep things around. :ls! shows that I currently have about 550 buffers open. we do have a large code base! Then get another 1-2 GB of RAM. It's not called memory leak when program allocates memory according to its functionality. Yakov I know perfectly well what a memory leak is; it isn't allocating memory according to its functionality, it is forgetting to free it according to its requirements. I was just debating whether allocation of an extra 100Kb was necessary if I created a few new splits for an existing buffer and then closed them. If someone provided the answer this memory is kept around for reason X, then it wouldn't be a memory leak. I currently have 4GB of RAM in this machine, but that can get eaten up surprisingly fast when you're doing what I do. I don't think 32-bit XP can address any more than that, can it? Max
Re: Vim memory leak
Max Dyckhoff wrote: [...] I do have 'hidden' set, because I like to keep things around. :ls! shows that I currently have about 550 buffers open. I know this seems like a lot, but we do have a large code base! [...] Keeping things around is one thing, keeping them in memory is another. By using :set hidden you _tell_ Vim to keep in memory the _whole data_ of every single buffer you visited during the current session, which IMHO is a little overdoing it. By setting 'nohidden' (and 'autowriteall' if, like me, you want to be able to close a window without a cry for unsaved data) you'll keep in memory only the data of the buffers currently displayed in a window, and a few bits of info (such as last cursor location etc.) for other buffers. The data itself would be where it belongs -- on disk, from where it can be reloaded in a twinkling of an eye if you happen to re-edit some file you've already edited in the current session. Or is all your large code base on diskettes? Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 162. You go outside and look for a brightness knob to turn down the sun.
RE: Vim memory leak
Thanks Tony, A.J.Mechelynck wrote: Keeping things around is one thing, keeping them in memory is another. By using :set hidden you _tell_ Vim to keep in memory the _whole data_ of every single buffer you visited during the current session, which IMHO is a little overdoing it. By setting 'nohidden' (and 'autowriteall' if, like me, you want to be able to close a window without a cry for unsaved data) you'll keep in memory only the data of the buffers currently displayed in a window, and a few bits of info (such as last cursor location etc.) for other buffers. The data itself would be where it belongs -- on disk, from where it can be reloaded in a twinkling of an eye if you happen to re-edit some file you've already edited in the current session. Or is all your large code base on diskettes I agree that it's a little extreme keeping it all around, but I like having the undo buffers for files I've closed recently kept around. This is either because I accidentally close the last tab containing that file, or because I have marks set in files which I use regularly. I should note that the memory use of vim does still grow constantly (and apparently unboundedly) even without opening new buffers, with '-u NONE', 'nohidden', and 'history=1'. I'm not sure if the code base is actually large, but 8,000 source files certainly seems pretty hefty to me. And thankfully no, our it isn't on diskettes :) Max
Re: Vim memory leak
Max Dyckhoff wrote: Thanks Tony, A.J.Mechelynck wrote: Keeping things around is one thing, keeping them in memory is another. By using :set hidden you _tell_ Vim to keep in memory the _whole data_ of every single buffer you visited during the current session, which IMHO is a little overdoing it. By setting 'nohidden' (and 'autowriteall' if, like me, you want to be able to close a window without a cry for unsaved data) you'll keep in memory only the data of the buffers currently displayed in a window, and a few bits of info (such as last cursor location etc.) for other buffers. The data itself would be where it belongs -- on disk, from where it can be reloaded in a twinkling of an eye if you happen to re-edit some file you've already edited in the current session. Or is all your large code base on diskettes? I agree that it's a little extreme keeping it all around, but I like having the undo buffers for files I've closed recently kept around. This is either because I accidentally close the last tab containing that file, or because I have marks set in files which I use regularly. marks are remembered in the viminfo file (see :help viminfo) even when the file is not in memory, indeed even when Vim is not running. For the undo history it's not as simple. I should note that the memory use of vim does still grow constantly (and apparently unboundedly) even without opening new buffers, with '-u NONE', 'nohidden', and 'history=1'. I'm not sure if the code base is actually large, but 8,000 source files certainly seems pretty hefty to me. And thankfully no, our it isn't on diskettes :) Max Thankfully indeed! Best regards, Tony. -- I don't think so, said René Descartes. Just then, he vanished.
Re: Vim memory leak
:sp on a new buffer causes a raise of 4-8K. :q on a split causes a raise of 4-8K. Switching to/from gvim causes a small increase, typically 4-8K for a few switches. Searching (with *) for a word in a .c file (with syntax highlighting) causes it to increase. If you hold down * then you can see the memory usage rocket up. Basically, pretty much any action. Any ideas? Will I just have to live with it and restart my vim session every couple of days? A couple things you might try experimenting with: -does it happen in naked vim? (started via vim -u NONE) -does it happen when you drastically reduce your 'undolevels' parameter? (and what is it set to currently?) -what sorts of vimscripts are getting run that might be creating or storing values but not releasing them? -what sorts of things are being fired on events? Particularly the CursorHold-ish events where something is happening with every movement. -what sorts of auto-completion options do you have running? I would imagine that omni-completion with C/C++ syntax might take a bit of memory to house. These would be the first places I'd look for trouble. I regularly have vim up almost as long as WinXP at work (disrupted only by annoying reboots and blue-screens) and rarely have trouble with it. Even when I do, it's my own dumb fault for using vim to edit ISO images, 300+meg SQL scripts or something equally asinine. A :bwipe usually restores my poor vim session to fully-functional. -tim
