Re: Optimizing SVN switch

Bill Soudan <bill@soudan.net> writes:

> I don't know much about the SVN internals yet but it looks like
> there's two 'resource walks' here, one where it removes all the
> wcprops (thus wrinig END to each file) which takes ~136s and then
> the second where it sets the updated key/value which takes ~124s.

You're absolutely right:

> > 5.9175s - read wcprops for each file & dir & then set to 'END'

Yes, this is the "clean 'em out" walk.

> > 143.1844s - read wcprops for each file & dir & then set to new value

And this is the "set 'em up" walk.

We have two walks because the wc-props are a cache system, and bad
stuff happens if the cache is wrong. So, we clear the cache
(painstakingly) before the switch so we don't wind up with a race
condition should something break during the switch. Then afterwards,
the REPORT response gives us back all the new cache values, which we
then write to disk.

We could lose the second of these walks and amortize the cost of
having no cache across the set of future operations (the first we
needed the Version Resource URLs for a given path, we'd have to ask
the server for it and cache it).

We could probably speed up the first of the walks by just 'rm-ing' the
wcprops files instead of reading and writing empty ones, though I'm
just guessing at that (and don't know what kind of other pains that
might cause).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 9 21:39:30 2004