Re: CVS (v1.11) performance on Cygwin 1.1.8

["Charles S. Wilson" <cwilson at ece dot gatech dot edu>]

Mark Allan Young wrote:
> 
> We have a linux server running CVS 1.10.7.
> 
> After upgrading our cygwin distributions, we've noticed that
> the cvs performance has gone complete down the tubes.
> 
> Using a 1.10.8 version of CVS seems to do much better.
> 
> Doing a "cvs co" of our source tree, comprised of 8087 files,
> (127Mb), we see the time go from about 1 minute to four minutes.
> 
> We're running Windows2000 SP1+hotfix.
> 
> we're looking at upgrading our linux server, but I was curious
> if anyone else has run into similar performance problems.

Yes, I have several reports that cvs 1.11.0 on cygwin is slower than
1.10.8.  Also that cvs (any version) on cygwin is slower than would be
expected when compared to, for instance, the same cvs version on Linux
-- even when taking into account the "typical" cygwin hit. (much work
has been done speeding up cygwin itself; the "hit" is not nearly as bad
as it once was).  But cygwin-cvs is still slow.

Jason Molenda sent me the following info, which may be of use:

> I don't know if this is an outstanding problem or if it's been
> resolved (I'm not following the cygwin list), but I do know a case
> where cvs will do this. [upload entire working dir when updating]
> 
> In a user's checkout, the CVS client keeps the last-mod date of
> files in its CVS/Entries file.  If a file has a newer timestamp,
> cvs-client assumes that the file may have been changed by the user,
> so that file is uploaded to the cvs-server during an update operation.
> 
> If all files have been touched in this manner, or the timestamps
> are screwed somehow, then all the files in that person's checkout
> will be uploaded.
> 
> Incidentally, this is a simple way to bring down most cvs servers
> - cvs admins will put cvs' temporary space on some tiny little
> partition (because it rarely needs more than a few megabytes per
> concurrent user), and then someone will touch all the files in
> their checkout and do a 'cvs update'.  The temp space needs to be
> as big as the largest possible checkout to handle these rare cases. :-/
> 
> Running cvs as 'cvs -t update' should give you a better feel for
> what cvs is up to.  It's pretty verbose, but it makes it a little
> easier to figure out cvs is doing.

I am officially asking for help here: can some interested party who is
affected by this slowdown of cvs please debug/profile it, and perhaps
locate where in the code the slowdown occurs?  (Yes, I'm maintaining the
cygwin port of cvs -- but I don't think that means I'm supposed to do
ALL development and debugging of the package on this platform; cygwin is
a cooperative enterprise, no?)

Thnaks,
Chuck Wilson

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple