<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Strace on Segflow</title><link>https://segflow.github.io/tags/strace/</link><description>Recent content in Strace on Segflow</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 05 Sep 2022 11:20:00 +0100</lastBuildDate><atom:link href="https://segflow.github.io/tags/strace/index.xml" rel="self" type="application/rss+xml"/><item><title>What strace -c taught me about a fast CLI</title><link>https://segflow.github.io/post/strace-c-fast-cli/</link><pubDate>Mon, 05 Sep 2022 11:20:00 +0100</pubDate><guid>https://segflow.github.io/post/strace-c-fast-cli/</guid><description>&lt;p&gt;The CLI was fast. I had benchmarked it on my laptop, on a fresh clone of the
repo, and it finished in well under a second. Then a coworker pointed it at a
real monorepo, the kind with 30,000 files spread across a few thousand
directories, and the thing crawled. Same code, same machine class, just more
files. The user-visible work had not changed. The wall clock had.&lt;/p&gt;
&lt;p&gt;This is the story of the half hour I spent figuring out why, what &lt;code&gt;strace -c&lt;/code&gt;
showed me, and why I now reach for it before any profiler when something
&amp;ldquo;feels slow&amp;rdquo; on Linux.&lt;/p&gt;
&lt;p&gt;My first instinct was wrong, by the way. I assumed disk. The repo was big,
the laptop has an NVMe drive but it is not magic, and &amp;ldquo;more files&amp;rdquo; sounds
like &amp;ldquo;more IO.&amp;rdquo; So I ran the program twice in a row, expecting the second
run to be fast off the page cache. It was not. Both runs took roughly the
same time. Whatever was slow, it was not waiting on the disk.&lt;/p&gt;</description></item></channel></rss>