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