<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Memory on Lorbic</title><link>http://localhost:1313/tags/memory/</link><description>Recent content in Memory on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 13 Aug 2026 18:00:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/memory/index.xml" rel="self" type="application/rss+xml"/><item><title>How Go Channels Actually Work</title><link>http://localhost:1313/go-channels-deep-dive/</link><pubDate>Thu, 13 Aug 2026 18:00:00 +0530</pubDate><guid>http://localhost:1313/go-channels-deep-dive/</guid><description>&lt;p>A single unbuffered channel send without an active receiver is enough to silently lock up a production worker pool, leaking memory until your service gets killed by the OS kernel.&lt;/p>
&lt;p>On the surface, Go channels look simple: they synchronize concurrent execution without manual mutex management. But under heavy load, a minor oversight in channel sizing or worker coordination blocks the scheduler, leaks memory, or crashes processes with runtime panics.&lt;/p>
&lt;p>&lt;picture class="optimized-image-container">&lt;source srcset="http://localhost:1313/go-channels-deep-dive/go-scheduler-meme_hu_524f15f4ab89fd6f.webp 480w, http://localhost:1313/go-channels-deep-dive/go-scheduler-meme_hu_50f95d885458376d.webp 646w" sizes="(max-width: 800px) 100vw, 800px" type="image/webp">&lt;img src="http://localhost:1313/go-channels-deep-dive/go-scheduler-meme_hu_50f95d885458376d.webp" width="646" height="797" alt="The Go scheduler coordinating 10,000 goroutines on a single-core CPU" loading="eager" decoding="async" fetchpriority="high" class="img-fluid" />
 &lt;/picture>&lt;/p></description></item><item><title>Go Struct Field Alignment: How Memory Padding Wastes Your RAM</title><link>http://localhost:1313/go-struct-field-alignment/</link><pubDate>Sat, 24 Jan 2026 10:00:00 +0530</pubDate><guid>http://localhost:1313/go-struct-field-alignment/</guid><description>&lt;p>You write a struct to represent a database entity. Maybe 10 fields, maybe 20. What could possibly go wrong?&lt;/p>
&lt;p>Nothing, according to your tests. But somewhere in production, your heap is 30% larger than it should be, your Garbage Collector is working overtime, and your L1 cache is not used properly. The reason? &lt;strong>Invisible padding bytes&lt;/strong> silently inflating every instance of your struct.&lt;/p>
&lt;p>This is the story of struct field alignment: a memory optimization that costs nothing to implement but can significantly improve performance.&lt;/p></description></item><item><title>Memory Mechanics In Go - Stack vs Heap</title><link>http://localhost:1313/memory-mechanics-stack-vs-heap-in-go/</link><pubDate>Mon, 12 Jan 2026 00:10:00 +0530</pubDate><guid>http://localhost:1313/memory-mechanics-stack-vs-heap-in-go/</guid><description>&lt;p>We often talk about &amp;ldquo;fast&amp;rdquo; code in terms of Big O notation or algorithmic complexity. But in systems programming languages like Go, &amp;ldquo;fast&amp;rdquo; is often a function of &lt;em>where&lt;/em> your data lives in memory.&lt;/p>
&lt;p>When optimizing for high throughput, efficient loops and database indexes are only part of the story. Eventually, you have to talk about the Stack and the Heap.&lt;/p>
&lt;p>Understanding the difference isn&amp;rsquo;t just trivia. It is the difference between a service that hums along at 100k OPS with flat latency, and one that chokes on Garbage Collection (GC) pauses every few seconds.&lt;/p></description></item></channel></rss>