bzr too slow

[Denys Duchier]

John Arbash Meinel <john at arbash-meinel.com> writes:

> Well, hash-cache is written whether we hold a write lock or a read lock.
> It is a cache file that cannot be invalid, just incorrect. (It gets
> corrected if it is incorrect.)
> The same thing is true for .bzr/basis-inventory.
>
> Both are atomically written, and contain information to invalidate
> themselves if they are out of date.
> Which is why it is okay to write them outside of the lock.

I understand all this, but if you write the hashcache outside the protection of
a lock (whether read or write), then there is always the chance that a write
transaction could take place in between the time when you release the lock and
the time when you write back the hashcache.  Thus you'll overwrite correct data
with incorrect data.  It is safe to do so, but not especially clever.

The case of multiple concurrent read transactions also has problems: each
transaction may update different parts of the hashcache.  Ideally when writing
back the hashcache, we should only merge into the on-disk hashcache the entries
that we have actually updated during the transaction.  In this manner,
"up-to-date-ness" of the on-disk hashcache would be monotonic.

> Otherwise, if you really only want to do it when the lock is held, you
> can do:
>
> if self.branch._lock_count == 1:
>   # write hash cache
> return self.branch.unlock()

all this hackery to avoid doing the right thing makes me a little sad.

--Denys