[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: wc_db performance (was: wc_db API discussion)

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 11 Mar 2011 22:39:21 -0500

2011/3/11 Branko Čibej <brane_at_e-reka.si>:
> On 12.03.2011 01:29, Greg Stein wrote:
>> So. Not a premature optimization, but a design choice.
> Six of one, half a dozen of the other. ACTUAL is just another op-depth
> with a few extra attributes, so let's compromise and call it an
> implementation choice, rather than a design choice. :)

No. It was a design choice. Simple as that.

Since the time that design was constructed, we have learned more. We
have refined our models, we have found implementation issues, we have
rebuilt the code into new ways, etc etc. I take issue with your
characterization. We designed with what we knew at the time, rather
than "prematurely optimized" the code or "made an implementation

> Right now I'm seeing C code do:
>    * recursive tree walks of the wc-db with per-directory queries
>    * programmatic "joins" of data from different tables
>    * op-depth filtering on NODES
> Much as I try, I can find no good reason, even taking account of the
> considerations you listed above, to /not/ do these in SQL. There aren't
> all that many radically different queries you can do in wc-db anyway.

That may be. But remember the wc_db API was originally designed to
ease the migration from the 1.6 WC mechanisms. Tree walks is how it
worked. There was no SQL, so everything happened in memory. And there
certainly was no "op_depth". So yeah... with yet more work, we can
make the additional changes you describe.


Received on 2011-03-12 04:39:56 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.