On Sun, 27 Nov 2005, Daniel Berlin wrote:
>
> > GCC tree GCC tree w/prop svn tree
> > svn st 11% 33% 64% 92% 53% 25%
> > svn diff 12% 27% 30% 45% 40% 0% (*)
> > svn ci 40% 86% 80% 95% 78% 50%
> >
> > *) There were small time differences, but it was hard to measure.
> >
> >
> > One could go into detail analyzing these numbers, but I'm not sure how
> > much that would give us. There are too many factors that can have an
> > effect on the numbers. If someone want to test this in more depth, feel
>
> Do you happen to have numbers from svn update?
>
> That is probably a more common operation than svn update for the gcc
> tree :)
>
>
>
>
Yeah, I did some testing with a local repository today just out of
curiousity. I both tested with an 1.3 build from trunk some weeks ago and
the latest 1.2 sources. It makes some improvements, but not that much. I
didn't investigate, but does svn up read all properties? Maybe it is the
cached svn:externals that shows?
Note that using a filesystem where the node type isn't stored in the
directory, you might get other performance characteristics. There, you'll
have another stat per file, and disk block reading to get all stat
information.
But I made another nice observation while upgrading my WCs from the
revision with no properties to the revision with svn:eol-style=native for
each file. I took 10 minutes to update that using the old client and 4
minutes when using wc-propcaching. This is a nice number as well, although
changing the properties on each file (only) shouldn't be that a common
operation.
I've noticed that for update, we rewrite the entries files even if nothing
was changed. We might want to get rid of that...
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 11:48:14 2005