On Wed, Jan 12, 2011 at 09:46:47AM -0500, C. Michael Pilato wrote:
> Nothing to add to the immediate discussion at this time. Just wanted to
> note that we have essentially the same problems to deal with in the BDB
> backend. The solution we've taken there is "don't drive public API
> callbacks from inside BDB transactions". It's not always the best for
> performance, but the FS API is such a high profile API for third-party
> consumers (very unlike the WC API in that respect, I'd imagine) that
> simplicity of the API "rules" was valued.
>
This is about callbacks in the libsvn_client(!) and libsvn_wc APIs.
Those are widely used by third parties so we should really make
the right decision.
Do we trust third parties to heed restrictions we place on callbacks?
There is no way can enforce the restrictions. We can only document them
and hope that third party developers play along. However, this would
give us the best performance we can theoretically get (based on the
assumption that the number of sqlite queries we run is a major
limiting factor).
Or we could decide not to run callbacks while sqlite transactions
are in progress, and pay some performance overhead. We'd have to
run multiple queries and provide data to the callback in chunks
(of, say, directory-sized units). I'm not sure if this would provide
adequate performance, but I haven't taken any measurements either (yet).
A recent change of this kind I made to the node walker didn't make
to make any notable difference.
We may need both approaches anyway, if we decide to use the second
approach in backwards-compat code.
Opinions?
Stefan
Received on 2011-01-13 14:26:19 CET