<?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 Lorbic</title><link>http://localhost:1313/tags/performance/</link><description>Recent content in Performance on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 31 Jul 2026 23:00:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>Couchbase Index Best Practices and Query Performance Tuning</title><link>http://localhost:1313/couchbase-index-best-practices-performance-tuning/</link><pubDate>Fri, 31 Jul 2026 23:00:00 +0530</pubDate><guid>http://localhost:1313/couchbase-index-best-practices-performance-tuning/</guid><description>&lt;p>Most Couchbase performance tickets I have seen end the same way: someone adds more nodes, the dashboard looks a little better for a week, and the same query shows up in the slow log a month later. The node count was never the problem. The index was.&lt;/p>
&lt;p>This is a working reference, not an essay. I already wrote &lt;a href="http://localhost:1313/what-couchbase-taught-me-about-system-thinking/">the reflective version&lt;/a> of what indexing in Couchbase teaches you about systems in general. This post skips the reflection and gets straight to the decisions: which index type to reach for, how to order composite keys, how to tell if a query is actually using what you built, and which four or five mistakes account for most of the slow queries you will ever debug. Couchbase&amp;rsquo;s own documentation is the primary source for the recommendations below. Every example runs against &lt;code>travel-sample&lt;/code>, the sample bucket Couchbase ships with every install, so you can paste these into your own cluster and see the plan yourself.&lt;/p></description></item><item><title>Cache-Driven Development: Saving Your Database From Itself</title><link>http://localhost:1313/cache-driven-development/</link><pubDate>Wed, 22 Jul 2026 12:00:00 +0530</pubDate><guid>http://localhost:1313/cache-driven-development/</guid><description>&lt;p>There is a moment in every backend engineer&amp;rsquo;s life when their database starts refusing connections.&lt;/p>
&lt;p>Picture 2 a.m. on a Tuesday. The app is operating under normal traffic, nothing unusual. But the database connection pool is saturated. Queries are timing out. The monitoring dashboard shows 50,000 database operations per second, far beyond what the system should be handling.&lt;/p>
&lt;p>When someone pulls the slow-query logs, the pattern is immediately clear. The same query appears thousands of times:&lt;/p></description></item><item><title>So, We Are Writing Efficient Software Again</title><link>http://localhost:1313/so-we-are-writing-efficient-software-again/</link><pubDate>Wed, 17 Jun 2026 20:00:00 +0530</pubDate><guid>http://localhost:1313/so-we-are-writing-efficient-software-again/</guid><description>&lt;p>I wanted to upgrade the RAM in my PC.&lt;/p>
&lt;p>Nothing fancy. I bought 32GB in 2024 and I wanted to double it. I opened a tab, checked the price, and closed the tab. Then I sat quietly for a moment.&lt;/p>
&lt;p>The same 32GB kit I bought in 2024 now costs more than double. DDR5 prices have gone up roughly 400% since mid-2025 [1]. DDR4 is not much better. A kit that cost $60–$90 in late 2025 now sells for $150–$180 [2].&lt;/p></description></item><item><title>Constructing Concurrent Inverted Indexes in Go</title><link>http://localhost:1313/constructing-concurrent-inverted-indexes-in-go/</link><pubDate>Tue, 16 Jun 2026 22:00:00 +0530</pubDate><guid>http://localhost:1313/constructing-concurrent-inverted-indexes-in-go/</guid><description>&lt;p>I spent a Saturday afternoon benchmarking a concurrent inverted index and discovered that a single &lt;code>sync.RWMutex&lt;/code> starts to break down at roughly 4 concurrent readers. The degradation is not linear. It is not graceful. It is a cliff.&lt;/p>
&lt;p>The inverted index is one of the oldest data structures in information retrieval. It maps terms to the documents that contain them, forming the backbone of every search engine from Elasticsearch to Lucene to Google&amp;rsquo;s earliest prototypes. The data structure itself is simple. Making it fast under concurrent load is not.&lt;/p></description></item><item><title>A Love Letter to the L1 Cache</title><link>http://localhost:1313/love-letter-to-the-l1-cache/</link><pubDate>Mon, 15 Jun 2026 19:00:00 +0530</pubDate><guid>http://localhost:1313/love-letter-to-the-l1-cache/</guid><description>&lt;p>I recently spent four hours staring at a benchmark that didn&amp;rsquo;t make sense.&lt;/p>
&lt;p>It started while working on &lt;a href="https://github.com/vikash-paf/derelict-facility" target="_blank" rel="noopener noreferrer">Derelict Facility&lt;/a>, my grid-based game engine in Go. I was trying to tighten the main update loop, specifically the part that iterates over every entity on the map each frame. I pulled out a small benchmark to isolate the cost, and something looked wrong.&lt;/p>
&lt;p>I had two Go structs. They held the exact same data: two booleans and a 64-bit integer. I was iterating over a slice of 10 million of these structs, doing a simple addition. They should have been identical in performance.&lt;/p></description></item><item><title>Why Explaining Technical Difficulty is Hard</title><link>http://localhost:1313/why-explaining-technical-difficulty-is-hard/</link><pubDate>Thu, 14 May 2026 01:00:00 +0530</pubDate><guid>http://localhost:1313/why-explaining-technical-difficulty-is-hard/</guid><description>&lt;p>&amp;ldquo;Can we just add a real-time visitor counter to the homepage? It&amp;rsquo;s just a query, right&amp;rdquo;?&lt;/p>
&lt;p>Every engineer has heard some variation of this. On the surface, the logic is sound. You have data, you have a UI, and you want to connect them. In the world of business requirements, this is a solved problem. You write a line of code, and the feature exists.&lt;/p>
&lt;p>But your database doesn&amp;rsquo;t care about business logic. It cares about &lt;strong>Infrastructure Constraints&lt;/strong>.&lt;/p></description></item><item><title>Building a Poor Document Store inside PostgreSQL</title><link>http://localhost:1313/building-a-poor-document-store-inside-postgresql/</link><pubDate>Sat, 09 May 2026 22:00:00 +0530</pubDate><guid>http://localhost:1313/building-a-poor-document-store-inside-postgresql/</guid><description>&lt;p>The marketing for &amp;ldquo;schemaless&amp;rdquo; architecture was brilliant. It promised speed, agility, and a life free from the tyranny of &lt;code>ALTER TABLE&lt;/code> migrations. When PostgreSQL introduced &lt;code>JSONB&lt;/code> in version 9.4, many developers saw it as a green light to treat Postgres like MongoDB.&lt;/p>
&lt;p>I’ve seen this pattern in dozens of codebases. It starts with a single &lt;code>metadata&lt;/code> column, but within months, the entire business logic is buried inside a 2MB JSON blob.&lt;/p></description></item><item><title>Why Your Goroutines Need a Speed Limit: Bounded Concurrency in Go</title><link>http://localhost:1313/bounded-concurrency-in-go/</link><pubDate>Fri, 10 Apr 2026 10:00:00 +0530</pubDate><guid>http://localhost:1313/bounded-concurrency-in-go/</guid><description>&lt;p>&lt;strong>TL;DR:&lt;/strong> Spawning &lt;code>go func()&lt;/code> without a limiter is a recipe for system collapse. This guide details how to use &lt;strong>Semaphores&lt;/strong> and &lt;strong>Worker Pools&lt;/strong> to prioritize predictable stability over absolute speed, protecting downstream dependencies from the thundering herd.&lt;/p>
&lt;hr>
&lt;p>It&amp;rsquo;s a rite of passage for every Go developer. You receive a list of 10,000 URLs to fetch or 50,000 rows to process. You wrap the workload in an unbounded &lt;code>go func()&lt;/code> loop, achieving maximum throughput in milliseconds.&lt;/p></description></item><item><title>Part 1: Data-Oriented Design in Go: Why [][]Tile Destroyed My Game Engine</title><link>http://localhost:1313/data-oriented-design-go-contiguous-memory/</link><pubDate>Sun, 05 Apr 2026 10:00:00 +0530</pubDate><guid>http://localhost:1313/data-oriented-design-go-contiguous-memory/</guid><description>&lt;p>Most game development stories start the same way: install Unity, drag some sprites onto a canvas, and press Play.&lt;/p>
&lt;p>I wanted to understand the metal. I set out to build &lt;em>&lt;a href="https://github.com/vikash-paf/derelict-facility" target="_blank" rel="noopener noreferrer">Derelict Facility&lt;/a>&lt;/em>, a systems-level game engine from scratch in pure Go. No SDL, no OpenGL wrappers, no Ebiten. The goal wasn&amp;rsquo;t just to ship a game; the goal was to learn the memory layouts and I/O pipelines that modern engines hide behind friendly APIs.&lt;/p></description></item><item><title>Understanding CPU Caches in Go</title><link>http://localhost:1313/cpu-caches-in-go/</link><pubDate>Tue, 31 Mar 2026 22:15:00 +0530</pubDate><guid>http://localhost:1313/cpu-caches-in-go/</guid><description>&lt;p>When you&amp;rsquo;re building Go services that handle millions of operations per second, the hardware beneath your abstractions starts to matter. Specifically, the CPU cache hierarchy, and whether your data fits in it.&lt;/p>
&lt;hr>
&lt;h4 id="the-hardware-context-its-not-just-ram">The Hardware Context: It&amp;rsquo;s Not Just &amp;ldquo;RAM&amp;rdquo;&lt;a class="anchorjs-link" href="#the-hardware-context-its-not-just-ram" aria-label="Link to section: The Hardware Context: It&amp;rsquo;s Not Just &amp;ldquo;RAM&amp;rdquo;">&lt;/a>&lt;/h4>&lt;p>Your server has 32GB or 64GB of RAM, but the CPU avoids touching it whenever possible. Instead, it works through a chain of caches:&lt;/p></description></item><item><title>WSL2 Is Slow? Fix /mnt/c/ File System Performance &amp; Go Latency</title><link>http://localhost:1313/wsl2-performance-tax-go-windows/</link><pubDate>Sun, 29 Mar 2026 22:30:00 +0530</pubDate><guid>http://localhost:1313/wsl2-performance-tax-go-windows/</guid><description>&lt;p>WSL2 (Windows Subsystem for Linux) has been a godsend for developers who love Linux tools but need/have a Windows environment. But for Go developers, WSL2 isn&amp;rsquo;t just a &amp;ldquo;transparent layer&amp;rdquo;. If configured incorrectly, it becomes the bottleneck that can slow down builds by 3x and introduce mysterious latency in networked services.&lt;/p>
&lt;p>This isn&amp;rsquo;t a failure of WSL2; it&amp;rsquo;s a failure of understanding the &lt;strong>9p boundary&lt;/strong>.&lt;/p>
&lt;div class="details-block reveal-item">
 &lt;details>
 &lt;summary>
 &lt;div class="summary-inner">
 &lt;span class="details-label">Glossary //&lt;/span>
 &lt;span class="details-title">What is the 9P Boundary?&lt;/span>
 &lt;svg class="svg-icon icon-plus" aria-hidden="true" focusable="false" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 448 512">&lt;path d="M256 80c0-17.7-14.3-32-32-32s-32 14.3-32 32V224H48c-17.7 0-32 14.3-32 32s14.3 32 32 32H192V432c0 17.7 14.3 32 32 32s32-14.3 32-32V288H400c17.7 0 32-14.3 32-32s-14.3-32-32-32H256V80z"/>&lt;/svg>
 &lt;svg class="svg-icon icon-minus" aria-hidden="true" focusable="false" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 448 512">&lt;path d="M432 256c0 17.7-14.3 32-32 32H48c-17.7 0-32-14.3-32-32s14.3-32 32-32H400c17.7 0 32 14.3 32 32z"/>&lt;/svg>
 &lt;/div>
 &lt;/summary>
 &lt;div class="details-content">
 &lt;p>WSL2 is a Virtual Machine. To let that VM see your Windows files, Microsoft uses the &lt;strong>9P protocol&lt;/strong> (Plan 9).&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><item><title>Go Garbage Collector Mechanics: Pacer, GOGC, and Allocation Latency</title><link>http://localhost:1313/dont-take-out-the-garbage-go-gc-deep-dive/</link><pubDate>Wed, 07 Jan 2026 00:21:12 +0530</pubDate><guid>http://localhost:1313/dont-take-out-the-garbage-go-gc-deep-dive/</guid><description>&lt;p>In the world of high-throughput backend services, we often obsess over the usual suspects of performance: database indexing, network latency, and algorithmic complexity. But recently, while debugging our core gateway service (&lt;code>backend-gw&lt;/code>), I encountered a bottleneck that defied standard logic.&lt;/p>
&lt;p>The service was &lt;strong>CPU-bound&lt;/strong>, yet active heap usage was surprisingly low (~200MB). P99 latency was spiking at random intervals, but database queries were returning in milliseconds.&lt;/p>
&lt;p>The culprit was not the business logic. It was &lt;strong>memory management&lt;/strong>. I was effectively running a Denial-of-Service attack on my own runtime.&lt;/p></description></item></channel></rss>