[MERGE] lsprof branch

[Robey Pointer]

On 19 Jun 2006, at 21:15, John Arbash Meinel wrote:

> 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.
>>
>> 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
>
> So how do you actually generate Calltree style output? I don't see any
> options to bzr to actually generate it.

I don't either, and there doesn't seem to be any in ddaa's original  
patch.  Maybe ddaa can clarify how it works?

(I can't use kcachegrind because I didn't/won't install KDE libraries  
on my mac.)


> So I figured I would use '--lsprof-file' to generate a pickle, and  
> then
> read that back in.
>
> But with the latest bzr.dev I have the problem that cPickle fails,
> because it can't serialize a 'code'.
>
> bzr: ERROR: cPickle.PicklingError: Can't pickle <type 'code'>:  
> attribute
> lookup __builtin__.code failed
>   at /home/jameinel/dev/bzr/bzr.dev/bzrlib/commands.py line 537
>   in apply_lsprofiled
>
> Now, I can see in 'Stats' that the method 'freeze()' claims to convert
> 'code' entries into string descriptions.
>
> This patch seems to fix it for me:

[snip] This code is from the original lsprof, but from scanning the  
code in your patch, I think the original indentation is correct.  It  
seems to be a really arcane way of doing string conversion on the  
fields.

What command did you lsprof?  I just tried it on "bzr info" and it  
worked here, so maybe a particular command is tickling it.


> So because everything was frozen so that you could pickle it, you  
> can't
> read it back in and create the call tree.

Here you are correct that once you freeze() the Stats object, it's no  
longer in the form that the calltree stuff is expecting.  I think  
ddaa intended calltree to be used inline (but I don't know how).

Maybe I should remove ddaa's patch since neither of us understands  
how to use it.  It seems like it's complicating things.


> Also, why doesn't running './bzr --lsprof-file foo root' actually run
> lsprof. It would seem like giving it an output file should be  
> sufficient
> for enabling the profiling.

That's a good idea; done.

robey