Hi Bram,

2014/5/10 Sat 20:23:47 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > 2014/4/29 Tue 22:04:23 UTC+9 Bram Moolenaar wrote:
> > > Ken Takata wrote:
> > > 
> > > > 2014/4/17 Thu 0:58:01 UTC+9 Adrian wrote:
> > > > > 'm helping another user open a large, 3Gb, file.  The standard windows
> > > > > editors balk, so I recommended VIM.  Unfortunately, even vim crashes
> > > > > after scrolling some amount.  For instance, he can't go straight to
> > > > > the end of file.
> > > > > 
> > > > > The work station is Windows 7, 64 bit, with 32Gb of RAM.  Are there
> > > > > any settings to modify to make vim more stable with large files, or is
> > > > > there some Windows performance limitation and just out of luck?
> > > > 
> > > > There is a related item in the todo.txt:
> > > > 
> > > > | Win64: Seek error in swap file for a very big file (3 Gbyte).  Check 
> > > > storing
> > > > | pointer in long and seek offset in 64 bit var.
> > > > 
> > > > I wrote some patches to fix this, but they seem to be still unstable.
> > > > 
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/support-largefiles-on-windows.patch?at=default
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/use-stat_T.patch?at=default
> > > 
> > > Did you make progress on this?
> > 
> > I wrote "still unstable", but it seems that it was my mistake.
> > Now I think that the patches are OK.
> > 
> > Sometimes Vim (without the patches) freezes when I open a very big file
> > (about 2 GB) and scroll up and down using scroll bar. After applying the
> > patches, Vim sometimes takes very long time for scrolling up and down, but
> > it wasn't a freeze. (I misunderstood that.)
> > 
> > BTW, I found that 32-bit Vim couldn't handle a very big file properly when
> > ":set noswapfile". In my understanding, this is an expected(?) behavior
> > because Vim tries to load the whole file into the memory when 'swapfile' is
> > off, and a 32-bit program can't allocate larger than 2-GiB memory.
> > (Actually, a 32-bit program can get 3-GiB user space if /LARGEADDRESSAWARE
> > option is specified for 'link'.)
> > 
> > 
> > > Can we also add some tests to verify the fix?
> > 
> > I'm thinking what is the best way to test this.
> > Something like this?
> > 
> > " Make sure that a line break is 1 byte.
> > :set ff=unix
> > :set undolevels=-1
> > " Input 99 'A's. The line becomes 100 bytes including a line break.
> > 99iA<Esc>
> > yy
> > " Put 19,999,999 times. The file becomes 2,000,000,000 bytes.
> > 19999999p
> > " Moving around in the file randomly.
> > G
> > 10%
> > 90%
> > 50%
> > gg
> > ...
> > " Edit some lines.
> > ...
> > " Extract some lines and write them to test.out.
> > ...
> 
> Although it would be good to test this way, I think it should not be
> part of "make test", since it will probably fail on smaller systems.
> Perhaps we should make a "make bigtest" target, for more testing.

I agree.


> Generally, I think we need to test that the patch doesn't break anything
> for normal editing.  But perhaps the tests we already have are
> sufficient for that.  If you look at your patch, are there any commands
> that would not be used by the existing tests?

I think that the existing tests cover almost all part, but maybe they
doesn't cover the following functions, commands and features:
 * getfsize(), getfperm(), getftime(), getftype()
 * :checktime
 * +cscope, +netbeans_intg

BTW, I have updated the patch:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/1ded06658094d26a5eef3ffe42e5edc94d93f59c/support-largefiles-on-windows.patch?at=default
 (same as before)
https://bitbucket.org/k_takata/vim-ktakata-mq/src/1ded06658094d26a5eef3ffe42e5edc94d93f59c/use-stat_T.patch?at=default
 * Define HAVE_STAT64 in vim.h and use it in os_mswin.c.
 * There was no need to use stat_T in os_unix.c. stat_T should be used with
   mch_stat().

Regards,
Ken Takata

-- 
-- 
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to