[MERGE] lsprof branch

[John Arbash Meinel]

Robey Pointer wrote:
> 
> On 18 Jun 2006, at 16:02, John Arbash Meinel wrote:

...

>>
>> Can you give us a reminder about what the major changes are? I see
>> something about doing threaded profiling, and something about Calltree
>> and various filtering.
> 
> I don't remember offhand, but I think I can piece it together from the
> log entries (wow, this stuff dates from February!).
> 
> Btw, the 'bzr status' display of pending merges kicks ass.  I never
> noticed that before.

It does as long as there aren't too many pending merges. I've merged
bzr.dev into an old long-lived branch before, and had 3 or 4 screens of
pending merges show up.
I wonder if we couldn't just show up to say 10 of them, with some sort
of "+400 other revisions, use --verbose to see them".
I believe we use 'merge_sorted' so we already have an idea which ones
are the more 'important' ones.

> 
> It looks like some of the patches have already made it in.  All that's
> left is:
> 
> * patch from ddaa to add kcachegrind output-format support to lsprof 
> [this is the _CallTreeFilter stuff]
> * add threading support -- each thread created during an lsprof session
> gets its own profile object, and the Stats objects are attached to a
> 'threads' member of the final Stats object
> 
> 
>> You import 'logging' at the top, but you never actually use it. Why?
> 
> Good catch; removed.  It was probably from earlier debugging.
> 
> 
>> Why all the threading calls. At least at present bzrlib is very single
>> threaded. (The only threads I know of are the server threads in the test
>> suite).
> 
> The paramiko stuff is also threaded.  I needed to add this to get
> profiling info on other threads, particularly when profiling sftp
> transfers to make sure paramiko wasn't a bottleneck.  At synchronization
> points, lsprof may show the main thread spending a lot of time in wait()
> -- this is where you want to look at the other threads to find out what
> they were doing.  Without this, most calls into paramiko look like "send
> something; wait".
> 

Okay.

> 
>> You add a parameter 'threads' to Stats, but you call it with an empty
>> dictionary.
> 
> Oh, I see what you mean.  What's going on there is that there's a single
> "primary" Stats object.  Separate Stats objects are attached to the
> 'threads' member, but they won't have sub-threads themselves, so they're
> always {}.
> 
> robey
> 

The changes seem reasonable enough to me. (+1) Is there any Gnome app
like KCacheGrind that we could support for those non-KDE users?

John
=:->


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