Branch.lock_read() rather expensive

John Arbash Meinel john at arbash-meinel.com
Sun Oct 16 15:43:17 BST 2005


Robert Collins wrote:
> On Sun, 2005-10-16 at 12:16 +1000, Martin Pool wrote:
> 
>>The policy is meant to be this:
>>
>> - Read locks are never required, because they can't be enforced over http
>>
>> - Read locks turn on caching of some objects in memory, so they can
>>make operations faster and give repeatable reads.  It's a good idea to
>>take and release the locks at a high level so that the cache is
>>effective and so there's not too much overhead.  Typically this should
>>be just below the command level.
> 
> 
> And further to that, *nested* read_lock calls should be for all intents
> and purposes, free. If they aren't, its a bug.

Well, I would like to see someone test it on another machine. Profiling
might be messing some of the timing up. It seems to make the mutter()
function call more expensive than it really is.

Because the difference in "time bzr cset" with mutter included or
commented out seems fairly small. But the "bzr --profile cset" seemed to
make a much bigger deal about it.

In general, you have a mutter, a conditional, an assert, and an
increment for each nested call. This isn't a lot, but it does seem to
add up when you call it 7k times.

What is really wierd is that the lock_read() call seemed more expensive
than the read_revision() call.

I'm also concerned that with --profile, the 12979 calls to
logging.debug() seem to pass all the way down to _log() which means it
has to create the record, and pass it on to the handlers.
Which seems that it is thinking the log will be written, even though I
don't have debugging turned on.

If you look back at the expenses, debug() calls account for 2.2 seconds.
Which is a very large portion of the overall run time.

John
=:->

> 
> Rob
> 

-------------- 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/20051016/49b73f97/attachment.pgp 


More information about the bazaar mailing list