[MERGE] lsprof branch

[Robey Pointer]

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

> Robey Pointer wrote:
>> With all the profiling and performance work being done, I thought  
>> it'd
>> be a good time to point out the lsprof branch again.  Since I haven't
>> needed to change it in a long time (except to merge bzr.dev), it'd be
>> nice to have it merged and not have to keep it up to date anymore.
>>
>> The branch lives here:
>>     http://www.lag.net/~robey/code/bzr.dev.lsprof
>>
>> robey
>
> 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 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".


> 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