<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Dtrace on vnykmshr</title><link>https://blog.vnykmshr.com/writing/tags/dtrace/</link><description>Recent content in Dtrace on vnykmshr</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 14 Nov 2010 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.vnykmshr.com/writing/tags/dtrace/index.xml" rel="self" type="application/rss+xml"/><item><title>Counting malloc</title><link>https://blog.vnykmshr.com/writing/counting-malloc/</link><pubDate>Sun, 14 Nov 2010 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/counting-malloc/</guid><description>&lt;p&gt;The program is as fast as I know how to make it. The hot loops are tuned, the locks as fine-grained as the design allows, the slow paths read and re-read. It&amp;rsquo;s still slower than it should be, and slow to start. The profiler keeps pointing at a name I&amp;rsquo;ve been ignoring because it isn&amp;rsquo;t mine: malloc.&lt;/p&gt;
&lt;p&gt;malloc holds a global lock, and in a multi-threaded program that lock is where the threads line up. You never wrote a line of it. The libraries you lean on allocate on paths you&amp;rsquo;ve never read. You can&amp;rsquo;t grep for it &amp;ndash; the calls aren&amp;rsquo;t in your code.&lt;/p&gt;</description></item></channel></rss>