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. The simplest workaround is to use an absolute path name when editing the file. I don't think there is any other way. Vim invokes getcwd() and that's a C library function, you probably can't do better than that. I have tried to avoid repeating calls to get the full file name. I know there is one more, when executing autocommands. It's not easy to avoid. You might make it faster by not having any autocommands trigger on write. -- How To Keep A Healthy Level Of Insanity: 9. As often as possible, skip rather than walk. /// 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 /// --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
