bzr too slow

[Denys Duchier]

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

> Well, you would have to read the file, and figure out which entries need
> to be modified. And since the fields aren't fixed width, you can't
> really replace inline. Even if you could, if you are interrupted while
> writing, you end up with a corrupted hash-cache.
>
> I suppose you could just append to the file, and define that the last
> entry for a given path is the correct one. But you again have the
> problem that now the file is always growing. And it really needs to be
> squished periodically.

Personally, I would prefer to use a cPickle for this data.  To update: get the
cache lock, unpickle the on-disk cache (if modified since read), transfer
modified entries, repickle it back to disk, release the cache lock.

> But the working tree can be changing underneath you anyway.

yes, and that remains fine. it is ok if the cache gets out of date. I am
proposing a method where it remains up to date more often than before.

> Or having two windows with 'bzr status' running. Pehaps running 'bzr
> status foo' and 'bzr status baz'.
> All of these cause race conditions with the hash-cache.

with the method I propose, they would both contribute to updating the cache.

> What we are doing right now is a hack because we know unlock() is always
> called. And we don't have a good place to put deferred actions.

I agree and what I propose is a first step for improving the situation.

> Having Transaction with a queue of things to do at cleanup isn't
> terrible. But Robert is the one who knows what the plan is for
> Transaction. (He wrote it in the first place.) So he seems like a good
> source for final decisions on how it should change.

Perhaps what I have in mind is something a bit more general that what is usually
understood by "transaction"; we might call it a "session".  I would require all
branch objects to be created in a "session".

Cheers,

--Denys