bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs is slooooooow with large directories


From: Derek Price
Subject: Re: cvs is slooooooow with large directories
Date: Tue, 08 Mar 2005 12:41:13 -0500
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Jones wrote:

| Andrew Morton writes:
|
|> On a dual 2.7GHz power4, the cvs client has racked up an hour of
|> CPU time so far.  There's something in there which is quadratic
|> (or worse) in the number of files in a directory.
|
|
| Yes, the fix for a release problem that Derek made a year ago
| (2004-02-25) is responsible for this behavior.  Prior to that fix,
| CVS would cache the Entries for a directory so that it wouldn't
| have to read (and possibly rewrite) the Entries file for each file
| being processed. Unfortunately, it sometimes changed to a different
| directory without flushing the cache, resulting in one directory's
| Entries ending up in a different directory.  Derek's fix removed
| the cache, so each new file being checked out ends up reading the
| Entries file, adding the new file, and then writing it back out,
| which is indeed quadratic behavior.  We need to figure out a way to
| restore the cache without reintroducing the original problem, a
| non-trivial task.


I've implemented part of this on a branch off 1.11.x named
(entries-cache).  It passes localcheck but not remotecheck - there are
still some places where client.c and maybe server.c are not accessing
Entries via the API, either writing or reading them directly.

If someone else would like to pick up the torch and correct the rest
of the entries references to use the official API, you are welcome
to.  Otherwise, I'll try and get back to this in a few days or weeks.

One final comment is that I implemented this based on 1.11.x, as noted
above.  I'm not sure this should be the final destination, but I
figured it would be easier to port forward than back.  At the very
least the current version introduces a dependency on the atexit()
function (available from GNULIB), but I am not sure this is desirable
on stable.

Regards,

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFCLeO5LD1OTBfyMaQRAsMGAJj/G84/x9VptHu4H8ReaYKRUANbAKDLFrHI
S8hSVieGbCKp8BgbP3bRrQ==
=zvUc
-----END PGP SIGNATURE-----






reply via email to

[Prev in Thread] Current Thread [Next in Thread]