<?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 gotest</title><link>https://mvrahden.github.io/go-test/tags/performance/</link><description>Recent content in Performance on gotest</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 06 Sep 2026 10:37:08 +0200</lastBuildDate><atom:link href="https://mvrahden.github.io/go-test/tags/performance/feed.xml" rel="self" type="application/rss+xml"/><item><title>Why Your Go Tests Are Slow (and What to Do About It)</title><link>https://mvrahden.github.io/go-test/blog/go-testing-at-scale/</link><pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate><guid>https://mvrahden.github.io/go-test/blog/go-testing-at-scale/</guid><description>&lt;p&gt;&lt;code&gt;go test ./...&lt;/code&gt; takes 90 seconds. You&amp;rsquo;ve profiled the hot tests and they&amp;rsquo;re fast. The database setup is cached. The assertions are trivial. So where does the time go?&lt;/p&gt;
&lt;p&gt;Usually the answer isn&amp;rsquo;t slow tests. It&amp;rsquo;s slow structure: the way tests are organized determines how much work runs sequentially, how much setup gets repeated, and how much parallelism the runtime can actually use. This post looks at the three structural patterns that make Go test suites slow, and what to do about each one. The payoff is real: the benchmark later in the post takes the same example suite from 6 seconds to 0.5 seconds through structural changes alone, without touching a single test.&lt;/p&gt;</description></item></channel></rss>