Re: cvs performance questions

[Eric Siegerman]

On Tue, Oct 21, 2003 at 02:10:46PM -0700, Richard Pfeiffer wrote:
> (some of the project directories in the repository are
> rather large, 357 Mb, etc)
>  
> 1)  If we have multiple users sharing the same userid, would
> that create any kind of locks, etc, that could hinder co/ci
> times?

Locks are certainly created, and that will certainly affect co/ci
times.  But the fact that multiple users share the same userid is
irrelevent.  (The practice is usually recommended against for
reasons of accountability, but it should have no impact on
performance.)

The overall size of the source tree being operated on will have
an effect here.  CVS's locking mechanism calls for creating
directories and/or files under *every* directory in the
repository that's to be visited, *not* just at the root of the
subtree of interest.  So locking overhead is O(N) on the number
of directories in the subtree, not O(1).  (But note that I said
"in the subtree".  If you do a "cvs co" on a leaf directory, i.e.
one containing only files, that'll be fast even if the repo as a
whole has thousands of directories.  Same if you do a "cvs co -l"
on any directory; since it doesn't recurse, it doesn't have to
lock the subdirectories.)

Of course, as the number of simultaneous users goes up (whether
or not they're sharing userids), the likelihood of their
contending for the same directories, and thus having to wait for
each others' locks, also goes up.


> 2) There is a great deal of branching taking place, and it has
> come to my attention that there are some  old undeleted tags
> hanging around.  Could enough of these cause a performance
> issue?

Sure, but the value of "enough" is likely *huge* :-)  Tags per se
don't take up much space, or, I imagine, much processing time.
Deleting old tags is unlikely to have a noticeable effect.  (It
can make "cvs log" output less cluttered, at the cost of losing
information of course; but DON'T do it merely as a performance
measure.)

What's more likely to slow things down is performing operations
on branches that:
  - were created many revisions ago
  - have many revisions on the branch

Specifically, the longer the path (along the revision tree) from
the revision you're working with to the one at the head of the
trunk, the longer the operation will take.  See rcsfile(5) for an
explanation.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
        - Michael Collins, Apollo 11 Command Module Pilot