On 16 Dec 2015 10:17 pm, Christian Brabandt <[email protected]> wrote: > > On Mi, 16 Dez 2015, Mike Williams wrote: > > > On 16/12/2015 19:14, Christian Brabandt wrote: > > >[HAVE_AVAIL_MEM] > > >>However, it does throw out the setting of maxmem/maxmemtot with it. > > >>The setting of maxmem/maxmemtot should be under a separate control > > >>IMHO. > > > > > >Yes that I thought as well. > > > > > >I remember when I debugged the blowfish corruption bug on Windows I > > >wondered why the maxmem/maxmemtot setting was so much lower than on > > >Linux. I wanted to suggest increasing that setting on Windows as well, > > >but forgot about it. > > > > The simplest fix is to up the default values for maxmem and > > maxmemtot on Win32 to match the values for unix: > > > > > > diff --git a/src/os_win32.h b/src/os_win32.h > > --- a/src/os_win32.h > > +++ b/src/os_win32.h > > @@ -123,11 +123,11 @@ > > #define TEMPNAMELEN _MAX_PATH /* length of temp file name path */ > > > > #ifndef DFLT_MAXMEM > > -# define DFLT_MAXMEM (2*1024) /* use up to 2 Mbyte for a buffer */ > > +# define DFLT_MAXMEM (5*1024) /* use up to 5 Mbyte for a buffer */ > > #endif > > > > #ifndef DFLT_MAXMEMTOT > > -# define DFLT_MAXMEMTOT (5*1024) /* use up to 5 Mbyte for Vim */ > > +# define DFLT_MAXMEMTOT (10*1024) /* use up to 10 Mbyte for Vim */ > > #endif > > > > /* > > Considering that even on my test Linux virtual machine with 2 GB of > memory the limit is about 1GB for maxmem and maxmemtot and considering > the increasing popularity of plugins as well as features like editing > multi GB logfiles and increasing complex undotree available, I still > think that 10 Mbyte and 5 Mbyte for Windows are still a little, err, > "limiting".
As I said, matching the unix defaults. In most cases these days there will be lots of memory available. Small system boards tend to come with custom built vi/vims, and you wouldn't try to do too much on them anyway. So yeah the default could be upped to say 64/512 but that is up to Bram. For now I set my preferred limits in my vimrc. > Even before patch 7.3.1142 that limit was a lot higher. > But I guess I can always script something in vimrc file with > wmic os get TotalVisibleMemorySize How about on Windows running a 32bit process on 64bit OS with 8GiB of RAM? Max mem usable is 4GiB, the limit for the virtual address space. Windows can report available virtual address for the process, what is left for the heap after the process is started which will be less than this. No point artificially limiting it to half of this is there? For a 64 bit process this is not practical, so what value should be used? On recent Windows, physical RAM less 250MiB for OS and its data should be more than adequate for maxmemtot to avoid paging and not be limiting. This suggests pushing the logic for default values down into mch_ functions so they can OS specific rather than applying a rough heuristic to all of them. TTFN > or something like that. > > Best, > Christian > -- > <Joey> Ich habe es damals als Unix-DAU aus der Manpage rausgelesen. > Wenn Du das heute nicht auf die Reihe bekommst, ist das peinlich. > -- #LinuxGER > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
