Re: cvs update times

[Eric Siegerman]

On Fri, Nov 14, 2003 at 01:55:55PM -0800, Richard Pfeiffer wrote:
> The project in question (Proj A) and one
> I'm using for comparison look like this:
>  
> Proj A is half the size as Proj B, but did have more directories.  I might 
> have to find out just how many more. 
> Proj A took 2m15s to checkout, Proj B took 10m30s.
> Proj A took 1m14s to update, Proj B to 1m20s.  

How long do the "du -k" commands take?  (Make sure the data is
*not* in the buffer cache.)  The time for a "du" is proportional
to total number of filesystem objects, not to directories
specifically, but the numbers might still be interesting.

> So Proj B is twice the Kb, takes 5 times longer to checkout but updates in 
> the same time as Proj A.

I'd be interested to know counts of files and directories for
both projects.  Not sure what use all these numbers would be, but
they couldn't hurt :-)

> I would just write it off to # of dirs, but users claim it was
> much faster last week.  I'll have to check and see if they
> checked in a bunch of files all in seperate directories, etc.

Hmm, it just occurs to me.  How about changes on the client side?
Could it be that the project-A people (but not the project-B
people) installed some app on their Windows boxes that interacts
badly with WinCVS?

Or in the network?  Is there a flaky hub in the project-A room,
or is someone there downloading DVDs in the background and
saturating their uplink? :-)

> Could indivdual file or directory sizes have any bearing?

Sure, they could be confusing the issue.  If project B has N
large files, and project A has N small files, I'd expect to see
something very roughly like you're seeing -- though the "twice
the KB, 5 times longer to check out" part is mystifying.  But
that aside, I'd expect the update times to be similar (assuming,
of course, that the sandboxes were already up to date).  Unlike
actually fetching updates, merely checking up-to-dateness isn't
proportional to the file sizes.

> Does a checkout's locking structure differ from an update's
> locking structure?  I wouldn't think so, but if that was true,
> I would think the co and update times would be proportional for
> these two projects.  

Didn't someone say that "co" locks the whole tree, but "update"
only locks one directory at a time?  I don't see how that would
affect things, though.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
        - Patrick Lenneau