Hotspot performance engineering fails
&gt; And that explain why companies do full rewrites of their code for performance: the effort needed to squeeze more performance from the existing code becomes too much and a complete rewrite is cheaper.<p>The article provides reasons why optimization gets harder, but no arguments for why a rewrite is better. It&#x27;s unclear whether the author is arguing for rewrites or whether they&#x27;re simply pointing out why companies take them on.<p>Arguably, though, companies taking on a full rewrite surely must have considered the cost of optimization (versus naively saying &quot;the system is slow, replace it!&quot;—though maybe some did). Rewrites are big, expensive, and time-consuming. It means new bugs and unknown unknowns, and no time to add features or fix bugs because you&#x27;re busy rewriting functional code. It&#x27;s a scapegoat for lack of improvement or progress. You shouldn&#x27;t take one on lightly.<p>At the same time, this post also neglects that some efficiency wins have little to do with the efficiency of the code, but rather the efficiency of the logic. An N+1 query in your application looks like your database is slow: you&#x27;re wasting a ton of time sitting and waiting for your DB to return information! But the real problem is that you&#x27;re repeatedly going back-and-forth to the database to query lots of little pieces of information that could have far more efficiently been queried all at once.<p>&gt; It is relatively easy to double the performance of an unoptimized piece of code, but much harder to multiply it by 10. You quickly hit walls that can be unsurmountable: the effort needed to double the performance again would just be too much.<p>That&#x27;s not really true, though. One bad SQL query can go from many seconds or minutes to milliseconds. One accidentally-quadratic algorithm can take orders of magnitude more time than a linear-time algorithm. One bad regexp can account for the majority of a request. Of course, as you fix the biggest performance problems, the only problems left are ones that are smaller than your biggest ones, so you&#x27;ll have diminishing returns.<p>But it also begs the question, what choices has your existing code made that makes it _ten times_ slower than you want it to be? In my experience, you&#x27;re doing work synchronously that could have been put in a queue and worked on asynchronously. It&#x27;s more often &quot;you&#x27;re doing more work than you should&quot; or &quot;you&#x27;re being inefficient with the resources you have available&quot; than &quot;a specific piece of code is computationally inefficient&quot;.