On Sun, Jun 14, 2009 at 3:17 PM, Bram Moolenaar <[email protected]> wrote:
> > Cháo wrote: > > > I recently ran into a very annoying issue with GVim's performance while > > editing files from a network shared from Ubuntu mapped mapped as a drive > in > > Windows XP. The main issue was saving a file taking a very long time > *(10-12 > > secs!!!)* and it turns out that most of the time VIM is spending > traversing > > each subdirs of the file same as switching buffers, such as these dirs: > > > > K:\ > > K:\main\ > > K:\main\comp\ > > K:\main\comp\base\ > > K:\main\comp\base\app\ > > K:\main\comp\base\app\admin\ > > K:\main\comp\base\app\admin\comp\ > > K:\main\comp\base\app\admin\comp\resource\ > > K:\main\comp\base\app\admin\comp\resource\en_US\ > > K:\main\comp\base\app\admin\comp\resource\en_US\strings\ > > > > > > I've attached a detailed log from FileMon (sysinternals) when I switch > from > > 1 buffer to another in GVIM and it took *about 7 seconds*. So the deeper > > the directory structure the file is located, the longer it would take > GVIM > > to save a file or to switch buffers. > > > > *Is this the wanted or correct behavior for GVIM to query / traverse each > > directory like so?* Maybe someone who's familiar with the GVIM code > could > > give me some light regarding the slow performance for traversing dirs > while > > working on a network share through VPN or any slow connection for that > > matter. > > > > Also attached is the logs for very slow saving of a file, maybe both are > > related. Both zip files each contain 2 diff formats for viewing > pleasure. > > I've decided to email vim_dev as well since it might have more dev > people > > who are watching this list, hope it's OK. > > This is probably caused by the code that figures out the full path name > on Unix. This is required to avoid any trouble with symbolic links. > Especially editing the same file under different names. > > Your directory is actually on a network share that doesn't support > symbolic links. But that's very difficult to detect. > > I'm not sure if there is any way to avoid this without compromising > reliability. Perhaps the expansion can be postponed or done in the > background. That would make it more complex. > > -- > How To Keep A Healthy Level Of Insanity: > 4. Put your garbage can on your desk and label it "in". > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net > \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/\\\ > \\\ download, build and distribute -- http://www.A-A-P.org > /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org > /// > Thanks for the quick reply, Bram! I thought there were a reason for traversing each dir like that. So can we have an option to turn this behavior off for those instances we know that we don't need to do such extra potentially slow work? Or if not, can you tell me where in code that I might be able to disable and compile myself a version without this behavior? It's really painful to a level where I am consider copying to locally and copy back to original server location! But that's not very ideal. Thanks, -- Cháo W. C. Fields <http://www.brainyquote.com/quotes/authors/w/w_c_fields.html> - "If I had to live my life over, I'd live over a saloon." --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
