bzr too slow

[John Arbash Meinel]

Denys Duchier wrote:
> John Arbash Meinel <john at arbash-meinel.com> writes:
> 
> 
>>Are you actually seeing the file getting written out repeatedly? If so,
>>I'll +1 a patch.
> 
> 
> I have a patch available as revision 1516 in the branch at:
> 
>            http://delta.univ-orleans.fr/~duchier/bzr/bzr.call_at_end
> 
> 
> I can confirm that this was _the_ major bottleneck for "bzr status".
> Previously, when running "bzr status" on my linux tree after I had touched all
> the files, I had to interrupt the process after 84mn.  With this patch, it
> completes in 4mn 51s.
> 
> The patch passes the test suite.
> 
> The idea of the patch is to extend transactions to allow registering callbacks
> to be executed at the end of the transaction.
> 
> Cheers,
> 
> --Denys
> 

Normally call_at_end functions are created in a LIFO queue, so that when
you do some sort of setup, it cleans itself up at the end.
I see you already have a check that the function isn't added more than once.

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

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

def __init__(self):
  self._call_at_end = set()

def register...
  self._call_at_end.add(foo)

But really I would rather see _call_at_end be a LIFO queue (list, where
you pop from the back at call time.)

But I like the idea of having 'cleanup' functions registered with the
transaction, which can happen when the transaction is finished.

I'm also concerned about the semantics of finish() versus commit(). Do
we always call Transaction.finish() whether we commit() or abort()?
Do we need a separate callback queue for things to run if the
transaction succeeds versus what happens if it is canceled?

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060110/e2102a93/attachment.pgp