<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Performance - Tag - Roland's Dev Blog</title><link>https://rolandsdev.blog/tags/performance/</link><description>Performance - Tag - Roland's Dev Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Fri, 14 Aug 2026 16:00:00 +0900</lastBuildDate><atom:link href="https://rolandsdev.blog/tags/performance/" rel="self" type="application/rss+xml"/><item><title>How musl (and a lucky accident) cut my Rust service's memory</title><link>https://rolandsdev.blog/posts/glibc-to-musl-rust-memory/</link><pubDate>Fri, 14 Aug 2026 16:00:00 +0900</pubDate><author><name>rolandjitsu</name><uri>https://github.com/rolandjitsu</uri><email>rolandjitsu@gmail.com</email></author><guid>https://rolandsdev.blog/posts/glibc-to-musl-rust-memory/</guid><description><![CDATA[<p>I had a Rust service that ate memory for breakfast. The fix that helped the most, I stumbled into completely by accident - and it had nothing to do with the code I&rsquo;d been sweating over &#x1f605; .</p>
<p>Here&rsquo;s the whole embarrassing, hopefully useful story.</p>
<h2 id="the-setup" class="headerLink">
    <a href="#the-setup" class="header-mark"></a>The setup</h2><p>The service was a data collector - high-throughput ingest with backpressure, checkpointing, retries, the usual. The design was simple: one thread reads batches of records off a source on a tick, hands them to another thread over a channel, and that thread ships them to a destination.</p>]]></description></item></channel></rss>