On Sep 11, 2009, at 8:18 PM, Greg Stein wrote:
> As stsp notes, this is an artifact of continuing to use multiple
> sqlite databases. Shoot ... we still haven't integrated the multiple
> property files into the databases. That represents a *TON* more I/O
> then our target implementation.
One of the other reasons the performance has gone down on trunk has
been the transition itself. wc-1 has grown *tons* of caching hacks
over the past several years, and while these have provided incremental
improvement, they are part of what caused the pile of spaghetti that
is the code base today. As part of the transition, we've stripped
most of the caching out of the client, and will re-evaluate what needs
to be added as the migration get's farther down the road. (SQLite
does a fair amount of internal caching, and that may meet our needs
sufficiently.)
The other part of this is reading entries. We're migrating away from
svn_wc_entry_t, but we've added a few convenience functions for
callers which such a migration isn't yet practical. If the entry's
access baton isn't cached (which fewer and fewer are, again due to the
migration work), we temporarily open the access baton, read *all* the
entries, and then dump the whole thing, probably to do it over again.
This is *incredibly* wasteful, but the very nature of the API is that
it is a temporary API and won't make the release, so these slowdowns
are also temporary.
It should also be noted that as the number of uses of entries goes
down, the actual reading of them will continue to dominate the
information retrieval time, until such time as the last use of
svn_wc_entry_t disappears. When that happens, I believe there will be
an immediate (and marked) performance increase.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2394126
Received on 2009-09-13 00:09:19 CEST