bzr too slow

Denys Duchier duchier at ps.uni-sb.de
Tue Jan 10 19:31:19 GMT 2006


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

> You also do some weird:
>
> x = y
> if not x:
>   x = {}
>   y = x
> x[foo] = None
>
> Why not just do:
>
> if not y:
>   y = {}
> y[foo] = None

because x is a local variable and y is actually an attribute access. this is the
sort of typical micro-optimization that just comes naturally.

> And even more so, you could just use a set(), and then do

indeed. I am just not familiar with sets in Python.

> I'm also concerned about the semantics of finish() versus commit(). Do
> we always call Transaction.finish() whether we commit() or abort()?

we call Transaction.finish() when we release the lock

> Do we need a separate callback queue for things to run if the
> transaction succeeds versus what happens if it is canceled?

I'd prefer not to make things complicated until the need really arises.  At
present, I only intend "at end" callbacks to save non-precious data that may be
computed/updated during the transaction.  I don't think we need LIFO semantics
yet nor different queues for success/failure.

If we ever do, then of course that can be added easily.

Cheers,

--Denys






More information about the bazaar mailing list