<?xml version="1.0" encoding="utf-8"?>
<!-- name="generator" content="pyblosxom/1.2.1 06/01/2005" -->
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN" "http://my.netscape.com/publish/formats/rss-0.91.dtd">

<rss version="0.91">
<channel>
<title>ddaa bbloggs   </title>
<link>http://ddaa.net/blog/python/lsprof-calltree</link>
<description>Some free bits of software.</description>
<language>en</language>
<item>
    <title>lsprof meets KCachegrind</title>
    <link>http://ddaa.net/blog/python/lsprof-calltree.html</link>
    <description>&lt;p&gt;You can now visualize the output of the &lt;a class=&quot;reference&quot; href=&quot;http://codespeak.net/svn/user/arigo/hack/misc/lsprof&quot;&gt;lsprof&lt;/a&gt; Python profiler using
&lt;a class=&quot;reference&quot; href=&quot;http://kcachegrind.sourceforge.net/&quot;&gt;KCachegrind&lt;/a&gt;, an excellent visualization tool for profiling data.&lt;/p&gt;
&lt;p&gt;One useful feature of the &lt;a class=&quot;reference&quot; href=&quot;http://docs.python.org/lib/module-hotshot.html&quot;&gt;hotshot&lt;/a&gt; Python profiler is the existence of the
hotshot2calltree conversion filter, that produces output suitable for
KCachegrind. So after the &lt;a class=&quot;reference&quot; href=&quot;http://thread.gmane.org/gmane.comp.python.devel/73166&quot;&gt;s/hotshot/lsprof&lt;/a&gt; thread occured on the
python-devel mailing list, and that &lt;a class=&quot;reference&quot; href=&quot;http://bazaar.canonical.com/Bzr&quot;&gt;Bazaar-NG&lt;/a&gt; added support for lsprof, I
was itching to use KCachegrind with lsprof data.&lt;/p&gt;
&lt;p&gt;In good libre software style, I eventually scratched my itch and wrote &lt;a class=&quot;reference&quot; href=&quot;/patch/lsprof-calltree.patch&quot;&gt;a
patch&lt;/a&gt; to add calltree support to lsprof. The lsprof maintainers are welcome
to apply it.&lt;/p&gt;
&lt;p&gt;With lsprof and KCachegrind I was able to quickly identify a performance bug in
Bazaar-NG that should be easy to fix. The data generated by hotshot completely
misses that issue, at least when displayed by KCachegrind. I am not sure why.&lt;/p&gt;
&lt;p&gt;One thing I know for sure is that hotshot2calltree has a serious bug. It causes
KCachegrind to confuse multiple functions with the same name and from the same
Python file. That completely messes up the call graph and greatly reduces the
pertinence of the data.&lt;/p&gt;
&lt;p&gt;Specifically, the Bazaar-NG code uses two decorators, &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;needs_read_lock&lt;/span&gt;&lt;/tt&gt; and
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;needs_write_lock&lt;/span&gt;&lt;/tt&gt;, defined in the same module, which return closures of
local functions called &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;decorated&lt;/span&gt;&lt;/tt&gt;. Each decorator uses a different
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;decorated&lt;/span&gt;&lt;/tt&gt; function, but hostshot2calltree produces data that causes
KCachegrind to only see one &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;decorated&lt;/span&gt;&lt;/tt&gt; function. In the example I&apos;m looking
at, it&apos;s the one in the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;needs_write_lock&lt;/span&gt;&lt;/tt&gt; decorator.&lt;/p&gt;
&lt;p&gt;KCachegrind seems to make C/C++ assumptions, and seems not to expect two
different functions with the same name and in the same file. My lsprof patch
works around the issue by including the Python module names and line numbers
into the function names in the calltree output. Incidentally, that also makes
for more informative names.&lt;/p&gt;</description>
  </item>
	    <item>
      <title>lsprof meets KCachegrind</title>
      <link>http://ddaa.net/blog/python/lsprof-calltree/python/lsprof-calltree</link>
      <description>&lt;p&gt;You can now visualize the output of the &lt;a class=&quot;reference&quot; href=&quot;http://codespeak.net/svn/user/arigo/hack/misc/lsprof&quot;&gt;lsprof&lt;/a&gt; Python profiler using
&lt;a class=&quot;reference&quot; href=&quot;http://kcachegrind.sourceforge.net/&quot;&gt;KCachegrind&lt;/a&gt;, an excellent visualization tool for profiling data.&lt;/p&gt;
&lt;p&gt;One useful feature of the &lt;a class=&quot;reference&quot; href=&quot;http://docs.python.org/lib/module-hotshot.html&quot;&gt;hotshot&lt;/a&gt; Python profiler is the existence of the
hotshot2calltree conversion filter, that produces output suitable for
KCachegrind. So after the &lt;a class=&quot;reference&quot; href=&quot;http://thread.gmane.org/gmane.comp.python.devel/73166&quot;&gt;s/hotshot/lsprof&lt;/a&gt; thread occured on the
python-devel mailing list, and that &lt;a class=&quot;reference&quot; href=&quot;http://bazaar.canonical.com/Bzr&quot;&gt;Bazaar-NG&lt;/a&gt; added support for lsprof, I
was itching to use KCachegrind with lsprof data.&lt;/p&gt;
&lt;p&gt;In good libre software style, I eventually scratched my itch and wrote &lt;a class=&quot;reference&quot; href=&quot;/patch/lsprof-calltree.patch&quot;&gt;a
patch&lt;/a&gt; to add calltree support to lsprof. The lsprof maintainers are welcome
to apply it.&lt;/p&gt;
&lt;p&gt;With lsprof and KCachegrind I was able to quickly identify a performance bug in
Bazaar-NG that should be easy to fix. The data generated by hotshot completely
misses that issue, at least when displayed by KCachegrind. I am not sure why.&lt;/p&gt;
&lt;p&gt;One thing I know for sure is that hotshot2calltree has a serious bug. It causes
KCachegrind to confuse multiple functions with the same name and from the same
Python file. That completely messes up the call graph and greatly reduces the
pertinence of the data.&lt;/p&gt;
&lt;p&gt;Specifically, the Bazaar-NG code uses two decorators, &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;needs_read_lock&lt;/span&gt;&lt;/tt&gt; and
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;needs_write_lock&lt;/span&gt;&lt;/tt&gt;, defined in the same module, which return closures of
local functions called &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;decorated&lt;/span&gt;&lt;/tt&gt;. Each decorator uses a different
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;decorated&lt;/span&gt;&lt;/tt&gt; function, but hostshot2calltree produces data that causes
KCachegrind to only see one &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;decorated&lt;/span&gt;&lt;/tt&gt; function. In the example I&apos;m looking
at, it&apos;s the one in the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;needs_write_lock&lt;/span&gt;&lt;/tt&gt; decorator.&lt;/p&gt;
&lt;p&gt;KCachegrind seems to make C/C++ assumptions, and seems not to expect two
different functions with the same name and in the same file. My lsprof patch
works around the issue by including the Python module names and line numbers
into the function names in the calltree output. Incidentally, that also makes
for more informative names.&lt;/p&gt;</description>
      <category domain="http://www.sauria.com">python</category>
      <dc:date>2006-01-27T12:24:38Z</dc:date>
    </item>
   </channel>
</rss>