Re: binary performance (was Re: Subversion & Word)

On Wed, Mar 05, 2003 at 11:04:11AM -0800, Ben Collins-Sussman wrote:
> Brian Denny <brian@briandenny.net> writes:
> > speaking of binary performance, what about time performance?
> >
> > we have some largeish (~5MB each) binaries in our CVS repository. commits
> > and updates go pretty quick on new entries, but after a while they slow
> > down (we were seeing times of two minutes per file at the tip of a long
> > branch).
> >
> > i don't know enough about what goes on under CVS's hood to know exactly
> > what causes this phenomenon... (?)
>
> Probably because CVS uses RCS, and RCS files don't do any compression
> on binary files. Every time you save the the big binary file to CVS,
> the *entire* file gets prepended to the RCS file. That's why it takes
> longer and longer to access over time. I think.

Correct. When you make *any* commit, CVS will rewrite the *entire* file.
Heck, if you just tag the thing, it will get completely rewritten.

Combine that with the "no deltas" for binary files, and you'll see that 100
revisions of a 5 megabyte has just ballooned your ,v file in the repository
up to 500 megabytes. Each commit is going to take longer and longer.

As Greg Hudson stated, the access to the head will be fast -- that is at the
front of the file. But anything besides the head could potentially take a
while to find and access.

> > will subversion handle these cases better?
>
> That's the theory. An svn repository does binary compression on
> absolutely everything.

Well, we also have *much* faster access, and when we commit, the number of
previous revisions has zero effect on the time required to write out the new
copy.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org