I like the idea of reading in the background... As I know there is no threading so far in vim, isn,t it? But few things probably could be done in threads like syntax parsing for highlighting. Sometimes this is also an issue, for eg. when opening a huge xml file etc.
yes.... thanks for the "clear eyes"... I was hurrying to post the results, as I spent quite some time with measurement. The cumulative seconds are indeed 4.25 seconds... I did not check those, was looking in the time spent in %. However now I tested the following: src$ VIM=/usr/share/vim VIMRUNTIME=/usr/share/vim/vim71/ time ./vim - u ./.vimrc --noplugins -c":q" ../all3.c (I mean, I measured with time..) the time shown is 10.18user 1.52system 0:13.20elapsed so 13 seconds.... no idea why is so big difference between the time measured by time and gprof... What is important is that at the end the time spent to open the 600MB file and quit vim is 13 seconds.. I would like to tell you however, that this is not to blame vim... vim is the best editor!! On Jun 16, 7:52 am, Ben Schmidt <[EMAIL PROTECTED]> wrote: > misi wrote: > > Hello, > > > would like to use vim to edit large files (600mb). Unfortunatelly, it > > looks like opening such large files even on a Pentium 3.4Ghz with PATA > > disk takes quite some time (ubuntu, kernel 2.6.22-14). I know that vim > > creates some internal tree representation of the file, but I wonder if > > something could be tuned, so that such loading times decrease, even if > > memory usage would increase? > [...] > > time vim -u ./.vimrc --noplugin -c":q" ../all3.c > > > the result is: > > > real 0m17.670s > > user 0m15.457s > > sys 0m1.428s > > I think what is taking the time is actually reading the file from disk. > Vim reads the entire file into memory, and getting 600 MB off disk takes > time. > > [...] > > > I profiled vim, and opening the same file I got the file below.... > [...] > > Flat profile: > > > Each sample counts as 0.01 seconds. > > % cumulative self self total > > time seconds seconds calls s/call s/call name > > 46.12 1.96 1.96 1 1.96 4.22 readfile > > 23.53 2.96 1.00 31025600 0.00 0.00 ml_append_int > > 12.94 3.51 0.55 31025601 0.00 0.00 ml_updatechunk > > 8.24 3.86 0.35 31361959 0.00 0.00 ml_find_line > > 4.94 4.07 0.21 31025600 0.00 0.00 ml_append > [...] > > 0.00 4.25 0.00 11709 0.00 0.00 mch_breakcheck > > The profile only shows an execution time of four and a quarter seconds. > Is this really how long it took? If so, it's probably because most of > the file was cached in memory by the OS from your previous reading of > it. I don't think that kind of time is unreasonable by any means, and > although you could probably scrape a bit off it, I doubt it would be > worth it, as it would be likely to impair code readability somewhat, > and/or cause errors, and these are worse than slowness! If it didn't > take that long, I wonder what doesn't show up in the profile. Perhaps > the overhead of the function calls themselves. If that's the case, > optimisation would again be possible, but harder than optimising the > time that *does* show up, so again probably not worth it or unwise for > the same reasons as above. > > I may look into it a little more, particularly if you send back some > more details, but I doubt much can be done without a pretty big > overhaul--i.e. making Vim read in a background thread or lazily or such. > > Ben. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
