Re: cvs update times

[Richard Pfeiffer]

Thanks Eric.  I had actually thought of both of those and took quick looks:

 

1) There are no branches as of yet, so that nixed that thought!

 

2) I think the second thought is the one I need to investigate further.  Just wanted to see if the list concurred, or had ideas I overlooked.  I initially took a quick look at the directory structure while doing a du -k to see how large the project was getting.  

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.  

 

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

 

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.

 

Could indivdual file or directory sizes have any bearing?

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. 

 

Thx,

-R

 

 

 

 

 

  

Eric Siegerman <address@hidden> wrote:

On Fri, Nov 14, 2003 at 12:27:01PM -0800, Richard Pfeiffer wrote:
> However, we have one project in this repository that now takes
> 1:58 to checkout and 1:29 to update. It used to update much
> faster; these 'slow' update times just started occuring.

Two stabs in the dark:
- Are you on a branch, with large files and/or many revisions
between head of branch and head of trunk? Many operations in
CVS take longer under such circumstances, because of the way
revisions are stored in the ,v file (trunk as reverse deltas
from the head; branches as forward deltas from the branch
point. See rcsfile(5)).

- Does your slow project have a much larger directory:file
ratio than your other projects? If so, it could be that
locking overhead is dominating the total update time in that
project, whereas in your other projects it's the useful work
of updating revisions that dominates. CVS's locking overhead
is proportional to the number of directories (not files)
being operated on.

--

| | /\
|-_|/ > 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


_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs

---

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard