<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance on rjrowland</title><link>https://rjrowland.com/tags/performance/</link><description>Recent content in Performance on rjrowland</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 27 Jul 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://rjrowland.com/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>Profile First, Optimize Second</title><link>https://rjrowland.com/posts/engineering-practices-performance/</link><pubDate>Mon, 27 Jul 2026 09:00:00 -0500</pubDate><guid>https://rjrowland.com/posts/engineering-practices-performance/</guid><description>&lt;h2 id="measure-first-know-your-bottlenecks"&gt;Measure first, know your bottlenecks&lt;/h2&gt;
&lt;p&gt;Performance intuition is wrong more often than it&amp;rsquo;s right. The thing you&amp;rsquo;re certain is the bottleneck almost never turns out to be. Profile first and let the data decide where effort goes. There&amp;rsquo;s no reliable shortcut around this.&lt;/p&gt;
&lt;p&gt;Most web application code spends its time waiting, not computing. A request handler calls the database, waits, calls another service, waits, maybe hits a cache, waits again — and the CPU sits idle through nearly all of it. That&amp;rsquo;s why the common bottleneck categories skew so heavily toward I/O, roughly in this order of frequency:&lt;/p&gt;</description></item></channel></rss>