Thread: Re: Poor perfomance (was Re: setting default backup and swap dirs)
Cream is a free, easy-to-use configuration of the Vim text editor
Brought to you by:
digitect
From: Steve H. <dig...@mi...> - 2005-06-30 00:30:30
|
On Wed, 2005-06-29 at 14:39 -0700, Matt Wilkie wrote: > :cd ~ > > > > is it fixed? > > Yes! > > > Hopefully, we can track down where this is being set and fix it. > [...] > but :pwd still shows a network path. Here's a better fix, try: autocmd VimEnter,BufEnter * execute "cd " . [localpath] in your cream-autocmd.vim. (Where "[localpath]" represents a local path on your system such as $HOME or /tmp .) I think what is happening is that Vim changes the current working directory to that of a filename passed as an argument. In other methods of opening files (File > Open) this doesn't appear to happen. The test code you were using for Cream_file_open() just changed the file browser's initial path, also apparently not the same as :pwd. The fix above can not improve the initial delay at open, but should improve all later buffer editing. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-09-07 18:34:07
|
On Wed, 2005-06-29 at 20:29 -0400, Steve Hall wrote: > I think what is happening is that Vim changes the current working > directory to that of a filename passed as an argument. In other > methods of opening files (File > Open) this doesn't appear to happen. > The test code you were using for Cream_file_open() just changed the > file browser's initial path, also apparently not the same as :pwd. > > The fix above can not improve the initial delay at open, but should > improve all later buffer editing. I think that although you might see some improvement from this fix, it's not a complete solution. We ran the free (as in beer) File Monitor from www.sysinternals.com for Windows while scrolling through a file on a network drive. The resulting stream of file accesses to the file was alarmingly large compared to Vim without Cream. I guess this might be because a large number of autocmds in Cream that do file accesses are being triggered on a regular basis. But it's hard to say which ones might be problematic without getting inside Cream and tracing every single one, and in particular to determine if all of these accesses really necessary. The reason I mention this is I have some "power users" here who are quite unimpressed with Cream's performance compared to comparable editors like Slickedit. They've asked me if I can find a solution. Any ideas what to try next? Steve, would you please try the File Monitor test and tell me what you think? Ben |
From: BG - B. A. <BAr...@dy...> - 2005-09-07 18:36:46
|
On Wed, 2005-09-07 at 15:33 -0300, BG - Ben Armstrong wrote: > Steve, would you please try the File Monitor test and tell me what > you think? The particular utility I am referring to is here: http://www.sysinternals.com/Utilities/Filemon.html Ben |
From: Steve H. <dig...@mi...> - 2005-09-07 20:40:12
|
From: BG - Ben Armstrong, Sep 7, 2005 2:33 PM > > I think that although you might see some improvement from this fix, > it's not a complete solution. We ran the free (as in beer) File > Monitor from www.sysinternals.com for Windows while scrolling > through a file on a network drive. The resulting stream of file > accesses to the file was alarmingly large compared to Vim without > Cream. I guess this might be because a large number of autocmds in > Cream that do file accesses are being triggered on a regular basis. > But it's hard to say which ones might be problematic without getting > inside Cream and tracing every single one, and in particular to > determine if all of these accesses really necessary. > > The reason I mention this is I have some "power users" here who are > quite unimpressed with Cream's performance compared to comparable > editors like Slickedit. They've asked me if I can find a solution. > Any ideas what to try next? Steve, would you please try the File > Monitor test and tell me what you think? I can't use it, I don't have "Debug Program" privileges on my Windows machine. Cream *is* Vim. We just need to find what settings different than the default contribute to this behavior. What about &timeoutlen, if you put: set timeoutlen=1000 in your cream-conf, does it help? (Verify it is working at the command line.) -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: Steve H. <dig...@mi...> - 2005-09-07 21:25:38
|
From: Steve Hall, Sep 7, 2005 4:40 PM > From: BG - Ben Armstrong, Sep 7, 2005 2:33 PM > > > > [high latency problem over network] Found it! Cream tries to display the read-only status of a file in two places: the statusline and the window title. If you test: set statusline& set titlestring& in your cream-user, you should see this problem go away. Does that work? -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-09-08 11:39:36
|
On Wed, 2005-09-07 at 17:25 -0400, Steve Hall wrote: > Cream tries to display the read-only status of a file in two places: > the statusline and the window title. If you test: > > set statusline& > set titlestring& > > in your cream-user, you should see this problem go away. > > Does that work? That's it! Thanks. Looking forward to a proper fix so I can deliver this to my users. Obviously not having the status line at all is a Bad Thing. :) Ben |
From: Steve H. <dig...@mi...> - 2005-09-08 14:54:55
|
On Thu, 2005-09-08 at 08:38 -0300, BG - Ben Armstrong wrote: > On Wed, 2005-09-07 at 17:25 -0400, Steve Hall wrote: > > > > Cream tries to display the read-only status of a file in two > > places: the statusline and the window title. If you test: > > > > set statusline& > > set titlestring& > > > > in your cream-user, you should see this problem go away. > > > > Does that work? > > That's it! Thanks. Looking forward to a proper fix so I can > deliver this to my users. Obviously not having the status line at > all is a Bad Thing. :) A good temporary solution would be: 1. Add a line at the top of cream-statusline function Cream_statusline_filestate() to: return "" 2. Replace the cream-settings function Cream_titletext() lines: " modified if getbufvar(mybufnr, "&modified") == 1 let mymod = "*" else let mymod = "" endif to let mymod = "" I suppose we could make these automatic with some cream-conf var. But I've also been thinking about adding "performance settings" for large or high latency files. They could be meta controls for items like those above, as well as &lazyredraw, &swapfiles, &backup, :syntax and whatever else typically causes performance problems in select situations. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-09-09 14:45:36
|
On Thu, 2005-09-08 at 10:49 -0400, Steve Hall wrote: > A good temporary solution would be: > > 1. Add a line at the top of cream-statusline function > Cream_statusline_filestate() to: > > return "" > > 2. Replace the cream-settings function Cream_titletext() lines: > > " modified > if getbufvar(mybufnr, "&modified") == 1 > let mymod = "*" > else > let mymod = "" > endif > > to > > let mymod = "" Thanks. That works well enough. I'm wondering, though, if the modification flag could continue to be set, only far less frequently. I understand why the statusbar needs to be updated on the fly (e.g. to handle the updated current line #,) even when only scrolling, but ideally we don't need to worry about the modification flag at all when we're doing nothing but scrolling. Unfortunately, I don't know how we'd tell the difference between scrolling and other kinds of activity in the buffer, any of which might cause updates to the buffer. Can you think of any way? Also, once the modification flag is set, couldn't we stop checking it until the user performs an undo? Or are there ways other than undo of reverting to an unmodified state? > I suppose we could make these automatic with some cream-conf var. But > I've also been thinking about adding "performance settings" for large > or high latency files. They could be meta controls for items like > those above, as well as &lazyredraw, &swapfiles, &backup, :syntax and > whatever else typically causes performance problems in select > situations. That sounds reasonable, although it would certainly be better if we could find compromises that improve performance without losing functionality. Ben |
From: Steve H. <dig...@mi...> - 2005-09-10 22:28:21
|
On Fri, 2005-09-09 at 11:45 -0300, BG - Ben Armstrong wrote: > On Thu, 2005-09-08 at 10:49 -0400, Steve Hall wrote: > > A good temporary solution would be: > > [snip] > > Thanks. That works well enough. > > I'm wondering, though, if the modification flag could continue to be > set, only far less frequently. I understand why the statusbar needs > to be updated on the fly (e.g. to handle the updated current line > #,) even when only scrolling, but ideally we don't need to worry > about the modification flag at all when we're doing nothing but > scrolling. Unfortunately, I don't know how we'd tell the difference > between scrolling and other kinds of activity in the buffer, any of > which might cause updates to the buffer. Can you think of any way? > > Also, once the modification flag is set, couldn't we stop checking > it until the user performs an undo? Or are there ways other than > undo of reverting to an unmodified state? I'd rather not add overhead to monitor all the conditions that could cause a buffer modification. Besides, getbufvar() really should not be checking the file in the first place, only the buffer. That appears to be a Vim bug that would require too much effort on Cream's part to work around. > > I suppose we could make these automatic with some cream-conf var. > > But I've also been thinking about adding "performance settings" > > for large or high latency files. They could be meta controls for > > items like those above, as well as &lazyredraw, &swapfiles, > > &backup, :syntax and whatever else typically causes performance > > problems in select situations. > > That sounds reasonable, although it would certainly be better if we > could find compromises that improve performance without losing > functionality. True. Perhaps I'll ask on the vim list. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-09-12 11:23:07
|
On Sat, 2005-09-10 at 18:22 -0400, Steve Hall wrote: > I'd rather not add overhead to monitor all the conditions that could > cause a buffer modification. Besides, getbufvar() really should not be > checking the file in the first place, only the buffer. That appears to > be a Vim bug that would require too much effort on Cream's part to > work around. Agreed. That is rather odd. > True. Perhaps I'll ask on the vim list. Thanks. Please do. Ben |
From: BG - B. A. <BAr...@dy...> - 2005-12-06 16:57:13
|
On Fri, 2005-09-09 at 11:45 -0300, BG - Ben Armstrong wrote: > On Thu, 2005-09-08 at 10:49 -0400, Steve Hall wrote: > > A good temporary solution would be: > > > > 1. Add a line at the top of cream-statusline function > > Cream_statusline_filestate() to: > > > > return "" > > > > 2. Replace the cream-settings function Cream_titletext() lines: > > > > " modified > > if getbufvar(mybufnr, "&modified") == 1 > > let mymod = "*" > > else > > let mymod = "" > > endif > > > > to > > > > let mymod = "" > > Thanks. That works well enough. Or not ... I don't know what changed since I tested this, or if it was always broken but I never noticed. What I have observed with Filemon is that when Cream_titletext() or Cream_statusline_filestate() executes any expand(), there are disk accesses, e.g. let myfile = expand("%:p:t") I don't know why expand() should actually look at the file in the directory, but Filemon confirms that it does. It ought to be possible to manipulate a filepath following rules of syntax only, thereby completely eliminating any I/O. Because the titlestring and statusline are updated constantly, this makes Cream unusable when editing a file on a remote file share. The only completely effective workaround we have is the first one that you suggested: set statusline& set titlestring& The last time you tried testing on your Windows system using the Filemon utility, you reported you couldn't make it work because you lack "Debug Program" privileges which Filemon requires. Is this still the case? Ben |
From: BG - B. A. <BAr...@dy...> - 2005-12-06 17:48:02
|
On Tue, 2005-12-06 at 12:56 -0400, BG - Ben Armstrong wrote: > Or not ... Hold off on investigating this, though. It seems my Windows cream/gvim version is lagging behind the latest release, and in cream 0.33.1 we are using fnamemodify() instead of expand() which may resolve this issue. Ben |
From: Ben A. <BAr...@dy...> - 2007-09-04 14:02:14
|
Remember this one, Steve? Well, when we upgraded recently to 0.39, this broke again, so I had to reapply your fix. It would be nice if this could be implemented as a "performance feature" as you suggested so I wouldn't have to carry the patch forward from version to version. Thanks, Ben Steve Hall wrote: > On Thu, 2005-09-08 at 08:38 -0300, BG - Ben Armstrong wrote: > >> On Wed, 2005-09-07 at 17:25 -0400, Steve Hall wrote: >> >>> Cream tries to display the read-only status of a file in two >>> places: the statusline and the window title. If you test: >>> >>> set statusline& >>> set titlestring& >>> >>> in your cream-user, you should see this problem go away. >>> >>> Does that work? >>> >> That's it! Thanks. Looking forward to a proper fix so I can >> deliver this to my users. Obviously not having the status line at >> all is a Bad Thing. :) >> > > A good temporary solution would be: > > 1. Add a line at the top of cream-statusline function > Cream_statusline_filestate() to: > > return "" > > 2. Replace the cream-settings function Cream_titletext() lines: > > " modified > if getbufvar(mybufnr, "&modified") == 1 > let mymod = "*" > else > let mymod = "" > endif > > to > > let mymod = "" > > I suppose we could make these automatic with some cream-conf var. But > I've also been thinking about adding "performance settings" for large > or high latency files. They could be meta controls for items like > those above, as well as &lazyredraw, &swapfiles, &backup, :syntax and > whatever else typically causes performance problems in select > situations. > > > |
From: Steve H. <dig...@da...> - 2007-09-05 00:23:23
|
Ben, for now, you might try redefining these two functions in $CREAM."cream-user.vim" or in the Cream_conf_override() of a system-wide cream-conf: function! Cream_statusline_filestate() return "" endfunction function! Cream_titletext() ... let mymod = "" ... endfunction Then they will overwrite the corresponding Cream functions until somebody finds time to write a patch for this. :) -- Steve Hall [ digitect dancingpaper com ] :: Cream... usability for Vim :: http://cream.sourceforge.net On Tue, 2007-09-04 at 11:01 -0300, Ben Armstrong wrote: > Remember this one, Steve? Well, when we upgraded recently to 0.39, > this broke again, so I had to reapply your fix. It would be nice if > this could be implemented as a "performance feature" as you > suggested so I wouldn't have to carry the patch forward from version > to version. > > Thanks, > Ben > > Steve Hall wrote: > > On Thu, 2005-09-08 at 08:38 -0300, BG - Ben Armstrong wrote: > > > > > On Wed, 2005-09-07 at 17:25 -0400, Steve Hall wrote: > > > > > > > Cream tries to display the read-only status of a file in two > > > > places: the statusline and the window title. If you test: > > > > > > > > set statusline& > > > > set titlestring& > > > > > > > > in your cream-user, you should see this problem go away. > > > > > > > > Does that work? > > > > > > > That's it! Thanks. Looking forward to a proper fix so I can > > > deliver this to my users. Obviously not having the status line > > > at all is a Bad Thing. :) > > > > > > > A good temporary solution would be: > > > > 1. Add a line at the top of cream-statusline function > > Cream_statusline_filestate() to: > > > > return "" > > > > 2. Replace the cream-settings function Cream_titletext() lines: > > > > " modified > > if getbufvar(mybufnr, "&modified") == 1 > > let mymod = "*" > > else > > let mymod = "" > > endif > > > > to > > > > let mymod = "" > > > > I suppose we could make these automatic with some cream-conf var. > > But I've also been thinking about adding "performance settings" > > for large or high latency files. They could be meta controls for > > items like those above, as well as &lazyredraw, &swapfiles, > > &backup, :syntax and whatever else typically causes performance > > problems in select situations. > > > |
From: Steve H. <dig...@mi...> - 2005-12-06 18:43:31
|
From: BG - Ben Armstrong, Dec 6, 2005 12:47 PM > On Tue, 2005-12-06 at 12:56 -0400, BG - Ben Armstrong wrote: > > Or not ... > > Hold off on investigating this, though. It seems my Windows > cream/gvim version is lagging behind the latest release, and in > cream 0.33.1 we are using fnamemodify() instead of expand() which > may resolve this issue. My understanding is that expand() mods the buffer name based on the real filename. This involves relative and system path nomenclature and thus requires looking at the real file to accomplish. fnamemodify() is only a string manipulator, it accepts any string and modifies it based on known pathing principles (possibly based on the system). Cream requires the actual filename to be able to display the path in the window title, recently used file list, window list, etc. However, we should only expand this one time and from there rely on fnamemodify. I'm not able to look at a current (CVS) Cream at the moment, but I believe I remember doing a modification to do just this: expansion happens on open/save and is stored in a buffer var (b:cream_filename or similar) for all future needs. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-12-06 19:03:34
|
On Tue, 2005-12-06 at 13:43 -0500, Steve Hall wrote: > I'm not able to look at a current (CVS) Cream at the moment, but I > believe I remember doing a modification to do just this: expansion > happens on open/save and is stored in a buffer var (b:cream_filename > or similar) for all future needs. Yes, that's what I found. And it's in 0.33.1, too, so we're good. The Filemon tests pass with flying colours on it. Now, one of my users also reports that Microsoft Word loads large files several times faster than Cream, (again, across a slow network,) but I'll have him upgrade his Cream+Vim to 0.33.1 and retest to see if this is still a problem in the current version. Ben |
From: Steve H. <dig...@mi...> - 2005-12-07 01:50:27
|
On Tue, 2005-12-06 at 15:03 -0400, BG - Ben Armstrong wrote: > On Tue, 2005-12-06 at 13:43 -0500, Steve Hall wrote: > > I'm not able to look at a current (CVS) Cream at the moment, but I > > believe I remember doing a modification to do just this: expansion > > happens on open/save and is stored in a buffer var > > (b:cream_filename or similar) for all future needs. > > Yes, that's what I found. And it's in 0.33.1, too, so we're good. > The Filemon tests pass with flying colours on it. Good. For the record, this var is stored in b:cream_pathfilename and is expanded to the full proper name for the Cream session's current system. > Now, one of my users also reports that Microsoft Word loads large > files several times faster than Cream, (again, across a slow > network,) but I'll have him upgrade his Cream+Vim to 0.33.1 and > retest to see if this is still a problem in the current version. Cream slower than Word? No way! -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-12-07 15:20:00
|
On Tue, 2005-12-06 at 20:49 -0500, Steve Hall wrote: > Cream slower than Word? No way! Yes way. :) Here are his observations, both opening the same file: On my laptop from home using networked F drive via vpn connection: - cream: - until see the name of file on bottom screen 45sec - until see lines on the screen 30sec to 40sec more - Word - until see lines on the screen 11sec Cream opening a file on my local c drive is 3 sec so the problem is something that is slower when being done to a remote disk. Ben |
From: Steve H. <dig...@mi...> - 2005-12-08 01:47:43
|
On Wed, 2005-12-07 at 11:19 -0400, BG - Ben Armstrong wrote: > On Tue, 2005-12-06 at 20:49 -0500, Steve Hall wrote: > > > Cream slower than Word? No way! > > Yes way. :) Here are his observations, both opening the same file: > > On my laptop from home using networked F drive via vpn > connection: > > - cream: > - until see the name of file on bottom screen 45sec > - until see lines on the screen 30sec to 40sec more > > - Word > - until see lines on the screen 11sec > > Cream opening a file on my local c drive is 3 sec so the problem > is something that is slower when being done to a remote disk. > What version of Cream? Could you please also test with plain Vim? I'd like to verify this is caused by Cream scripts. A fix for high-latency read slowness was added 2005-09-13 and shows up in Cream 0.33.1. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: Matt W. <mat...@go...> - 2005-06-30 17:46:36
|
Hi Steve, > Here's a better fix, try: > > autocmd VimEnter,BufEnter * execute "cd " . [localpath] > > in your cream-autocmd.vim. (Where "[localpath]" represents a local > path on your system such as $HOME or /tmp .) That does it! And I can even keep the "open follows current doc" feature activated. Thank you very much for spending the time to get to the bottom of this Steve. I really appreciate it. take care, -- matt wilkie -------------------------------------------- Geographic Information, Information Management and Technology, Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax -------------------------------------------- |