On 10/21/05, Peter N. Lundblad <peter@famlundblad.se> wrote:
> On Fri, 21 Oct 2005, Garrett Rooney wrote:
>
> > So what's the solution to this problem? Well, for the verbose mode of
> > svn list we obviously still need this info, but for the non-verbose
> > mode it's totally useless. So I'd like to propose a new
> > svn_ra_get_dir2 function, which takes a new argument that indicates
> > what parts of the dirent you get back from the server. It'd look
> > something like this.
> >
> I tried both bdb and fsfs locally and bdb seemed to be about 6 times
> slower than fsfs (in my simple tests). Have you tested both bdb and fsfs
> vs. ra_dav and ra_svn? Are all cases slow?
>
> I remember a thread some time ago about ra_dav requesting too many
> properties in get_dir. I don't know if this has something to do with it.
Yes, ra_dav is definately slower than ra_svn in this case, at least
twice as slow in my tests.
The discussion you remember about ra_dav requesting too many
properties is the "deadprops" patch I referred to in my mail. In
short, it adds a new liveprop (deadprops-count) that just counts the
number of properties present for the entry, rather than the current
behavior which sends all of them across the network so they can be
counted on the client side. This reduces network traffic, and thus it
should improve matters (especially for the verbose case, when we do
actually need the info), but it doesn't get us all the way there for
the non-verbose case, since we still calculate a lot of stuff on the
server that we just throw away after we get it to the client. I have
no objection to applying the patch in question, I just want to take us
one step further and make the non-verbose case as fast as viewing the
directory in a web browser.
I haven't done bdb versus fsfs tests (all my tests were with fsfs),
but it seems like calculating and transmitting this data when we don't
need it will be a win any way you cut it, no matter which ra layer or
filesystem implementation we're talking about.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 22 01:06:15 2005