<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Explainers on JVQ.net</title>
    <link>https://jvq.net/tags/explainers/</link>
    <description>Recent content in Explainers on JVQ.net</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 18 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://jvq.net/tags/explainers/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Performance Budgets in CI Only Work When Base and Head Run Side by Side</title>
      <link>https://jvq.net/performance-budgets-in-ci-only-work-when-base-and-head-run-side-by-side/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://jvq.net/performance-budgets-in-ci-only-work-when-base-and-head-run-side-by-side/</guid>
      <description>&lt;p&gt;A performance budget is a promise written into the pipeline: this change may make the code at most 5% slower, and if it&amp;rsquo;s worse, the build fails. Tests already guard what the code does. A budget guards how fast it does it.&lt;/p&gt;&#xA;&lt;p&gt;The idea is old and simple. Making it work on ordinary CI machines is the hard part, because those machines are noisy. On the shared two-core cloud machine where jvq was tested, the very same benchmark binary, run 40 times in a row, spread by 8.9% from one run to the next. A budget of 5% sits well inside that noise, so a naive check can&amp;rsquo;t tell a real slowdown from the runner having a bad minute.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
