Re: the New Checkout System

On Tue, May 20, 2003 at 01:04:37PM -0500, Ben Collins-Sussman wrote:
>...
> Well Greg, the ethereal trace shows us exactly what we expect.

Actually, for the currrent checkout, I was expecting per-file PROPFINDs
*and* a Depth:1 PROPFIND on the directory. I guess the per-file ones got
fixed at some point :-)

>...
> you look through the ethereal trace, you see nothing but GETs on
> files, and depth-1 PROPFINDs on directories.

Excellent.

> In the new system, ra_dav is parsing an outline describing the entire
> tree to be added (names only.) Because every item is new ("added"),
> we only do depth-0 PROPFINDs on directories, and *both* a PROPFIND and
> GET on each file.

Yup. Expected.

> So all in all, the new system does many more network turnarounds, an
> extra PROPFIND on every file. The number of network requests is
> larger by approximately the number of files in the tree.
>
> That would explain a 35% speed decrease, right?

Definitely :-)

> Your suggestion makes sense. I think you mean, "when we see
> add-*directory* in the report", ra_dav can do depth-1 propfind, all
> the child props in memory, and thus avoid sending the extra PROPFIND
> per file.

Correct. The svn_ra_dav__get_props() function will return a hash table of
"resource" objects, which each include a hash of properties for that
resource. You can drop the sucker into the directory baton and just refer
back to it at add_file() or close_file() time in the editor drive.

> Should I proceed down that path? I don't think it will make the new
> system faster than the old; it will probably make it the same speed.

Agreed. I was expecting the "same perf" based on a faulty expectation for
the checkouts. But yah, we're definitely in a lose position if we don't fix
the update report processing.

I would recommend a two step process:

1) fix the report processing to use Depth:1 PROPFINDs whenever we see an
   add-directory items. this will help 'svn update' today.
2) apply your changes to switch over to the new checkout system. given (1)
   we will maintain performance parity.

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