“Use a mutex when writing. Use a Read-Write Lock (shared_mutex, sync.RWMutex, or pthread_rwlock) when reading, because multiple readers can read concurrently without blocking each other.”

It sounds great on paper.

Yesterday, after optimizing binary search on the Apple M2, I decided to test this textbook wisdom on an in-memory B+ tree. I wrapped the root with a standard std::shared_mutex, spawned threads, and ran 10 million pure read queries across M2’s 8 physical cores.

Here is what happened:

• On 1 core: 23.1 million ops/sec
• On 8 cores: 6.0 million ops/sec

Adding 7 more CPU cores made the database nearly 4x slower. A 74% throughput collapse on a workload that was doing 100% reads and zero writes.

How can an algorithm doing zero writes get slower as you add more CPU cores?

Because at the silicon level, read-locks are writes in disguise.

1. What a “Read Lock” Actually Executes

Open the implementation of pthread_rwlock_rdlock, C++’s std::shared_lock, or Go’s sync.RWMutex.RLock().

To allow multiple readers while keeping writers out, the mutex has to keep count of how many readers are currently active.

So when your thread calls shared_lock(), the CPU executes:

1// Inside pthread_rwlock / std::shared_mutex:
2atomic_fetch_add(&rwlock->reader_count, 1);  // <-- THIS IS AN ATOMIC WRITE

And when your thread is done reading:

1atomic_fetch_sub(&rwlock->reader_count, 1);  // <-- ANOTHER ATOMIC WRITE

You thought you were just reading data. In reality, every single read query performs two atomic writes to shared memory.

2. The Crime Scene: Cache Coherence & MESI

Why does writing an atomic integer matter if nobody is modifying the database keys?

Because modern multi-core processors do not share L1 caches. Every core on my Apple M2 has its own private, blazing-fast 64 KB L1 Data Cache.

To ensure all 8 cores see the same view of memory, the CPU hardware runs a cache coherence protocol called MESI (Modified, Exclusive, Shared, Invalid).

Here is what physically happens on the CPU bus when 8 cores try to acquire a “read lock”:

 1           ┌──────────────────────────────────────────────┐
 2           │      rwlock.reader_count (Atomic Integer)    │
 3           └──────────────────────┬───────────────────────┘
 4                                  │ Ping-Pong!
 5          ┌───────────────────────┴───────────────────────┐
 6          ▼                                               ▼
 7   ┌─────────────┐                                 ┌─────────────┐
 8   │ Core 0 (L1) │ ────[ BUS INVALIDATE Core 1 ]─> │ Core 1 (L1) │
 9   │ State: [M]  │ <───[ BUS INVALIDATE Core 0 ]── │ State: [M]  │
10   └─────────────┘                                 └─────────────┘
11      Atomic +1                                       Atomic +1
12   (Pipeline Stalled)                              (Pipeline Stalled)

1. Core 0 wants to increment reader_count. To write to that memory address, Core 0 must acquire Exclusive / Modified (M) ownership of that cache line. It broadcasts an INVALIDATE signal across the Apple M2 interconnect.
2. Cores 1 through 7 are forced to evict that cache line from their private L1 caches.
3. One nanosecond later, Core 1 wants to acquire its read-lock. It suffers an L1 Cache Miss because Core 0 just invalidated its line.
4. Core 1 stalls its instruction pipeline, waits for Core 0 to flush the cache line, and broadcasts its own INVALIDATE signal back across the crossbar.
5. Repeat across all 8 cores, 20 million times.

This phenomenon is known in database research as Cache-Line Bouncing or the Reader-Lock Scalability Collapse.

Even though your threads only wanted to read tree nodes, your CPU cores spent 90% of their clock cycles stalled, waiting for ownership of that single 128-byte cache line to ping-pong across the inter-core interconnect.

3. The Fix: Optimistic Lock Coupling (OLC)

The solution was popularized by the “German database school” (Viktor Leis, Alfons Kemper, and Thomas Neumann at TU Munich) in high-performance engines like HyPer and LeanStore:

If you want linear multi-core scaling, readers must write ZERO bytes to memory.

In Optimistic Lock Coupling (OLC), readers do not acquire any lock. They do not increment any reader counter. They execute with pure speculation:

The 64-Bit Version Primitive

Every node in the tree stores a single 64-bit integer:

1 63                                                         1   0
2┌────────────────────────────────────────────────────────────┬───┐
3│                    Version Counter                         │ L │
4│   (Even number when unlocked, incremented on write_unlock) │ K │
5└────────────────────────────────────────────────────────────┴───┘
6                                                               ▲
7                                         0 = Unlocked, 1 = Locked

• Bit 0 (LOCKED): 1 = exclusive write lock held, 0 = unlocked.
• Bits 1..63 (VERSION): A monotonic version counter incremented on every unlock.

 1class OptLock {
 2    std::atomic<uint64_t> version_{0};
 3    static constexpr uint64_t LOCKED_BIT = 0x1ULL;
 4
 5public:
 6    // Read Path: ZERO writes to shared memory!
 7    inline uint64_t read_lock_optimistic() const {
 8        uint64_t v = version_.load(std::memory_order_acquire); // Compiles to ARM64 LDAR
 9        while (__builtin_expect((v & LOCKED_BIT) != 0, 0)) {
10            asm volatile("yield" ::: "memory");
11            v = version_.load(std::memory_order_acquire);
12        }
13        return v;
14    }
15
16    // Validate: Did any writer touch this node while I was reading?
17    inline bool validate(uint64_t old_version) const {
18        return version_.load(std::memory_order_acquire) == old_version;
19    }
20
21    // Write Path: Exclusive lock via CAS on bit 0
22    inline void write_lock() {
23        uint64_t expected = version_.load(std::memory_order_relaxed);
24        while (true) {
25            if ((expected & LOCKED_BIT) == 0) {
26                if (version_.compare_exchange_weak(expected, expected | LOCKED_BIT,
27                                                   std::memory_order_acquire,
28                                                   std::memory_order_relaxed)) {
29                    return;
30                }
31            } else {
32                asm volatile("yield" ::: "memory");
33                expected = version_.load(std::memory_order_relaxed);
34            }
35        }
36    }
37
38    // Unlock: Advance version by 2 and clear locked bit
39    inline void write_unlock() {
40        uint64_t current = version_.load(std::memory_order_relaxed);
41        version_.store(current + 1, std::memory_order_release); // Compiles to ARM64 STLR
42    }
43};

How an OLC Read Works: Hand-over-Hand Validation

Instead of holding locks from parent to child down the tree, readers validate each hop optimistically:

 1               [ Parent Node ]  (Read Version: V_parent)
 2                      │
 3                      │ 1. Speculative read child pointer
 4                      ▼
 5               [ Child Node  ]  (Read Version: V_child)
 6                      │
 7                      │ 2. Validate Parent: version == V_parent ?
 8                      ├──────────────────────────┐
 9                     YES                         NO
10                      │                          │
11              3. Parent was intact!       Concurrently modified!
12                 Traverse down child         Abort & Restart from Root

When traversing down a tree from parent to child:

1. The reader reads parent->version using ARM64’s single-cycle LDAR (Load-Acquire).
2. It finds the child pointer and reads child->version.
3. It validates: parent->validate(parent_version).
4. If valid, it moves down. If invalid (a writer split the parent while it was reading), it restarts the search from the root.

Because readers execute only LDAR and never write a single bit:

• The cache line stays in state Shared (S) across all 8 L1 caches.
• Zero invalidate messages travel across the bus.
• All 8 cores read at full hardware bandwidth simultaneously.

4. The Hidden Trap: Memory Reclamation (EBR)

There is a catch.

If readers do not acquire locks, what happens when a writer splits or deletes a node while a reader is midway through traversing it?

If the writer calls delete node, the reader will dereference freed memory and crash with a segmentation fault (Use-After-Free).

To fix this without a heavyweight garbage collector, we use Epoch-Based Reclamation (EBR):

 1                 ┌───────────────┐
 2                 │  Epoch [ 0 ]  │
 3                 └───────┬───────┘
 4                         │
 5                 Advance │ (Active Readers Pin Current Epoch)
 6                         ▼
 7  ┌───────────────┐              ┌───────────────┐
 8  │  Epoch [ 2 ]  │ <─────────── │  Epoch [ 1 ]  │
 9  └───────┬───────┘   Advance    └───────────────┘
10          │
11          │ Objects retired in Epoch 2 can be freed
12          ▼ when ALL active threads have moved past Epoch 2!
13     Safe Bulk Free

• A global epoch rotates through 0 → 1 → 2 → 0.
• When a reader thread begins a query, it pins the current epoch: local_epoch.store(global_epoch);
• When a writer unlinks a node from the tree, it does not free() it. It pushes the pointer into an epoch retirement queue: retired_buckets[current_epoch].push_back(node);
• Once all threads have advanced past epoch G, objects retired in epoch (G + 1) % 3 are mathematically guaranteed to have zero active readers. They can be deallocated immediately in bulk without locks.

The Apple Silicon Rule: 128-Byte Alignment

On Apple Silicon, each thread’s epoch tracking struct must be aligned to 128 bytes (alignas(128)):

1struct alignas(128) ThreadEpochState {
2    std::atomic<uint64_t> local_epoch{UNPINNED};
3    std::atomic<bool> in_use{false};
4    std::array<std::vector<RetiredNode>, 3> retired_buckets;
5    size_t pending_count{0};
6    char pad[...];
7};

If you don’t align it to 128 bytes, adjacent cores dirty each other’s epoch variables, re-introducing false sharing and silently destroying your throughput.

5. The Benchmark: Real Numbers on Apple M2

I built a concurrent B+ tree using OLC and EBR and benchmarked it against std::shared_mutex across all 8 physical cores of the Apple M2.

Workload 1: 100% Reads (10,000,000 Lookups)

Look at the difference:

• std::shared_mutex collapsed by 74% as core count increased.
• OLC scaled smoothly up to 154.5 million lookups per second (a 25.8x leap).

Workload 2: 90% Read / 10% Write (5,000,000 Ops)

In real workloads, writers are constantly modifying the tree. Under standard locking, exclusive writers block all readers, and queued readers starve writers:

At 8 threads under mixed read/write contention, std::shared_mutex ground to a halt at 1.3 million ops/sec.

The OLC + EBR engine maintained over 109 million ops/sec—an 84x speedup—while safely retiring and reclaiming tens of thousands of nodes with zero data races and zero memory leaks.

Takeaways for Systems Engineers

1. Read-locks are writes in disguise: Any lock that increments an atomic counter turns concurrent reads into a cache-line invalidation storm.
2. Zero-write reading is the only path to linear scaling: Readers must use speculative loads (LDAR) and version checks instead of writing lock state.
3. EBR is essential for lock-free memory safety: You don’t need a heavy garbage collector to safely free memory in concurrent systems; a 3-epoch rotation does it with zero reader locks.
4. Respect 128-byte cache lines: Always isolate thread-local state with alignas(128) on Apple Silicon to prevent adjacent cores from invalidating each other’s state.

Reproducing the Benchmark

The complete self-contained C++ benchmark is hosted directly on this site:

• Source Code: /scripts/olc_ebr_benchmark.cpp

You can run it on your own Mac with:

1curl -sO https://mohit-k-s.github.io/scripts/olc_ebr_benchmark.cpp
2clang++ -O3 -std=c++20 -mcpu=apple-m2 -pthread olc_ebr_benchmark.cpp -o olc_bench
3./olc_bench

If you have a sorted array and need to find an element, you call std::lower_bound and move on.

A few days ago, I started wondering: on modern superscalar CPUs—specifically Apple Silicon (M2)—is std::lower_bound actually running as fast as the hardware allows?

Or is it leaving performance on the table?

To find out, I wrote a microbenchmark suite and tested several search implementations across array sizes ranging from 1,024 elements (4 KB, fits in L1 cache) to 8,388,608 elements (32 MB, spills into DRAM).

It turns out you can beat std::lower_bound by up to 2.9x.

Here is how, and why the hardware makes it possible.

The Hardware Reality: What Happens on Apple M2

To understand why traditional binary search struggles, you have to look at the CPU executing it.

My test machine is an M2 MacBook Pro:

• 8 CPU cores (4 Avalanche performance cores + 4 Blizzard efficiency cores)
• 64 KB L1 Data Cache per performance core
• 4 MB L2 Cache
• 128-byte cache line size (hw.cachelinesize = 128)

Apple’s performance cores are beasts. They have an 8-wide instruction decode engine and a massive reorder buffer (~600+ instructions). In an ideal scenario, the CPU executes several instructions per clock cycle.

But binary search exposes two major weaknesses in modern CPU architectures:

1. The Branch Misprediction Penalty: When you search for random keys, the comparison arr[mid] < target is true 50% of the time and false 50% of the time. It is mathematically the worst-case scenario for branch predictors. Every misprediction flushes the execution pipeline, costing 15 to 20 clock cycles.
2. The Cache-Locality Penalty: In a traditional sorted array, the first step checks index N/2. The next step jumps to N/4 or 3N/4 (megabytes away). The next step jumps hundreds of kilobytes away. Every step jumps to an unpredictable cache line.

Step 1: The Baseline (std::lower_bound)

Here is the standard binary search approach:

 1template <typename T>
 2int binary_search_branching(const T* arr, int n, T target) {
 3    int low = 0, high = n - 1;
 4    while (low <= high) {
 5        int mid = low + (high - low) / 2;
 6        if (arr[mid] < target) {
 7            low = mid + 1;
 8        } else if (arr[mid] > target) {
 9            high = mid - 1;
10        } else {
11            return mid;
12        }
13    }
14    return low;
15}

On a 65,536-element array (256 KB), std::lower_bound takes 32.26 ns per lookup.

For an algorithm that only does ~16 iterations (log₂(65536) = 16), 32 nanoseconds means every iteration is costing around 2 nanoseconds (~7 to 8 CPU clock cycles). The CPU is spending most of its time stalling on mispredicted branches.

Step 2: Branchless Binary Search on Sorted Arrays

Can we eliminate the if-else branches entirely?

Yes. Instead of branching on the comparison, we use conditional pointer arithmetic (often called Shar’s algorithm or branchless binary search):

 1int binary_search_branchless(const uint32_t* arr, int n, uint32_t target) {
 2    const uint32_t* base = arr;
 3    int len = n;
 4    while (len > 1) {
 5        int half = len / 2;
 6        // On ARM64, this compiles to CSEL (Conditional Select)
 7        base = (base[half] < target) ? base + half : base;
 8        len -= half;
 9    }
10    return (*base < target) ? (base - arr) + 1 : (base - arr);
11}

Notice what changed: there are no branches inside the while loop.

When compiled with clang++ -O3 -mcpu=apple-m2, Clang emits ARM64’s CSEL (Conditional Select) instruction. CSEL evaluates in 1 clock cycle regardless of whether the condition was true or false. Zero pipeline flushes.

The Result

• At N = 1,024 (4 KB): drops from 19.33 ns → 7.71 ns (2.5x faster).
• At N = 65,536 (256 KB): drops from 32.26 ns → 18.49 ns (1.7x faster).

By simply removing the branch, we doubled the speed. But when the array grows larger than L2 cache, another bottleneck takes over: memory access patterns.

Step 3: The Eytzinger (Breadth-First Heap) Layout

In a sorted array, the memory addresses accessed during binary search are scattered:

Sorted:   [ 10,  20,  30,  40,  50,  60,  70 ]
Index:       0    1    2    3    4    5    6
Step 1:                     ^ (mid)
Step 2:          ^ (or)               ^

Each step jumps across huge memory strides.

In the 1970s, Michael Eytzinger proposed a layout for binary trees that is identical to a binary heap:

• The root is stored at index 1.
• The left child of node k is stored at 2k.
• The right child of node k is stored at 2k + 1.

Sorted Array:      [ 10,  20,  30,  40,  50,  60,  70 ]
Eytzinger Layout:  [ 40,  20,  60,  10,  30,  50,  70 ]
Index:                1    2    3    4    5    6    7

Why is this brilliant for CPU caches?

Look at where the most frequently accessed nodes live:

• Index 1 (the root) is visited on every single search.
• Indices 2 and 3 (level 1) are visited on every single search.
• Indices 4, 5, 6, 7 (level 2) are visited on every single search.

Indices 1 through 15 take 15 × 4 = 60 bytes.

On Apple Silicon, a single cache line is 128 bytes.

That means the entire top 4 levels of the tree fit inside one single cache line! Once fetched, it stays permanently hot in the L1 Data Cache. The first 4 steps of any search will never incur a cache miss.

The Search Implementation

The traversal loop is astonishingly simple:

1int search_eytzinger_branchless(const uint32_t* arr, int n, uint32_t target) {
2    int k = 1;
3    while (k <= n) {
4        // Pure conditional arithmetic: compiles to 1-cycle CSEL on ARM64
5        k = 2 * k + (target >= arr[k] ? 1 : 0);
6    }
7    // Restore the index
8    return k >> (__builtin_ffs(~k));
9}

Every single iteration is two operations:

1. Compare target with arr[k]
2. Update k = 2 * k + condition

Zero branches. Zero branch mispredictions. Perfect cache locality at the top of the tree.

The Benchmark: Across Cache Boundaries

I ran 2,000,000 random lookups across five array sizes on the Apple M2:

Why Eytzinger Dominates at 32 MB

Look at the 32 MB result:

• std::lower_bound: 240.60 ns
• Eytzinger: 84.27 ns (nearly 3x faster)

When an array is 32 MB, standard binary search incurs cold DRAM cache misses right from the beginning because the root and first few subdivisions are megabytes apart.

With Eytzinger, the first 6 to 8 levels of the search are served directly out of L1 and L2 cache. The search only has to hit DRAM for the very last leaf accesses. Combined with zero branch mispredictions, latency drops from 240 ns down to 84 ns.

What About Software Prefetching?

In academic literature (e.g. Paul-Virak Khuong and Pat Morin’s 2017 paper “Array Layouts for Comparison-Based Searching”), they recommend adding software prefetch instructions to Eytzinger search:

1__builtin_prefetch(&arr[k * 16]); // Prefetch 4 levels ahead

I tested this on the M2:

At 65,536 elements:
Without prefetch:  14.57 ns
With prefetch:     67.62 ns  (4.6x SLOWER!)

Why did software prefetching make it worse?

Apple Silicon’s Avalanche cores have an aggressive hardware prefetcher. When you inject explicit PRFM (prefetch) instructions into a tight 1-cycle loop, you clog the instruction decode ports and instruction queue. For in-memory data structures on Apple Silicon, letting the hardware prefetcher do its job beats manual software prefetching.

Summary of Takeaways

1. std::lower_bound is branch-bound: Random binary searches on sorted arrays trigger ~50% branch mispredictions, stalling wide out-of-order CPUs.
2. CSEL is your friend: On ARM64, branchless conditional arithmetic executes in 1 cycle without pipeline flushes.
3. Data layout is an optimization: Sorted order is human-friendly; Eytzinger breadth-first layout is cache-friendly.
4. Hardware boundaries dictate wins:
   • For arrays fitting in L1 cache (N ≤ 1,024), branchless sorted search is fastest (7.1 ns).
   • For arrays exceeding L2 cache (N ≥ 1,000,000), Eytzinger layout wins by almost 3x because the tree root and top layers never leave CPU cache.

Reproducing the Benchmark

The full C++ benchmark source code and runner script are available directly on this site:

• Benchmark Source: /scripts/binary_search_benchmark.cpp
• Runner Script: /scripts/run_binary_search_benchmark.sh

You can reproduce the exact numbers on your Mac with:

1curl -sO https://mohit-k-s.github.io/scripts/binary_search_benchmark.cpp
2clang++ -O3 -std=c++20 -mcpu=apple-m2 binary_search_benchmark.cpp -o bs_bench
3./bs_bench

Recently I started learning C again and i was writing a small C program to calculate normal distribution intervals and intentionally omitted <math.h> just to see what would happen:

1#include <stdio.h>
2
3int main(void) {
4    printf("between -1.96 and 1.96 is: %g\n", erf(1.96 * sqrt(1/2.)));
5    return 0;
6}

I expected a generic “unknown function” or link error. Instead, Clang hit me with this:

1hello.c:6:36: error: call to undeclared library function 'erf' with type 'double (double)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
2hello.c:6:36: note: include the header <math.h> or explicitly provide a declaration for 'erf'
3hello.c:6:45: error: call to undeclared library function 'sqrt' with type 'double (double)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
4hello.c:6:45: note: include the header <math.h> or explicitly provide a declaration for 'sqrt'

Wait.

How does the compiler know erf takes a double and returns a double? How does it know sqrt belongs to <math.h> when <math.h> was never mentioned anywhere in the file?

A normal person would just add #include <math.h> and move on with their life.

I am not that person. Everything becomes a rabbit hole for me. I wanted to understand the exact mechanics of how the compiler knows this without the header, so I asked Gemini to dig around the Clang/LLVM source code and find where this is actually hardcoded.

1. The Compiler’s Secret Table

It turns out modern compilers don’t just parse C syntax—they have an internal database of the C standard library baked right into the compiler binary.

In Clang, this database historically lives in Builtins.def:

1BUILTIN(__builtin_erf , "dd", "Fne")
2BUILTIN(__builtin_sqrt, "dd", "Fne")

At first glance, "dd" looks like gibberish, but it’s Clang’s internal type encoding shorthand:

• First letter = return type (d = double)
• Subsequent letters = argument types (d = double)
• Attribute "F" = this is a standard library function that also exists without the __builtin_ prefix
• Attribute "n" = nothrow (won’t throw C++ exceptions)
• Attribute "e" = pure/const (no side-effects when floating-point exceptions are ignored)

And the required header name (math.h) is registered alongside it in Clang’s header descriptors.

2. Why is this an Error and Not Just a Warning?

Back in C89, if you called a function without declaring it, the compiler shrugged and assumed it returned an int:

1int erf(); // C89 implicit declaration assumption

On modern 64-bit architectures, this is a recipe for silent, catastrophic bugs:

• An int return value is passed in a general-purpose integer register (%rax on x86-64, x0 on ARM64).
• A double return value is passed in a floating-point/vector register (%xmm0 on x86-64, d0 on ARM64).

If the caller expects the result in an integer register while libm placed it in a floating-point register, you end up reading garbage memory.

Starting with ISO C99, implicit function declarations were deprecated, and modern Clang treats -Wimplicit-function-declaration as a hard error by default.

3. The Diagnostic Engine

When Clang parses an identifier like erf(...) and can’t find its declaration in scope, it doesn’t immediately crash or emit a generic error. It queries its built-in catalog:

1// Inside clang/lib/Sema/SemaDecl.cpp
2if (Context.BuiltinInfo.isLibFunction(BuiltinID)) {
3    const char *Header = Context.BuiltinInfo.getHeaderName(BuiltinID);
4    Diag(Loc, diag::ext_implicit_lib_function_decl_c99) << ...;
5    if (Header)
6        Diag(Loc, diag::note_include_header_or_declare) << Header;
7}

The error message and note you see are defined in DiagnosticSemaKinds.td:

1def ext_implicit_lib_function_decl_c99 : ExtWarn<
2  "call to undeclared library function '%0' with type %1; ISO C99 and later "
3  "do not support implicit function declarations">,
4  InGroup<ImplicitFunctionDeclare>, DefaultError;
5
6def note_include_header_or_declare : Note<
7  "include the header <%0> or explicitly provide a declaration for '%1'">;

4. How It’s Stored in Memory: Array or Map?

Once you realize the compiler has this catalog, the next natural question is: how is this actually loaded in memory? Does Clang parse a table from disk on startup, or search a giant hash map every time you type a word?

It turns out to be an elegant combination of both:

The Database: A Static Array in .rodata

The metadata is not parsed or loaded dynamically. It is defined as a compile-time constexpr static array (BuiltinInfos[]):

1// clang/lib/Basic/Builtins.cpp
2static constexpr Builtin::Info BuiltinInfos[] = {
3    // ...
4    // [238] = { NameOffset, TypeOffset, AttributesOffset, HeaderDesc::MATH_H } // erf
5};

Because it is compile-time constant data, it gets baked directly into the .rodata (read-only data) segment of the clang binary on disk.

When you run clang hello.c, the OS kernel memory-maps the binary into RAM. Zero parsing, zero disk reads, zero heap allocations. It is already in memory before your code is even touched. Accessing metadata by ID is an instant $O(1)$ array index.

The Lookup: The IdentifierTable Tag

An array is great if you already have the integer ID. But when the compiler lexes your code, it starts with the string "erf". Doing a linear scan over thousands of builtins for every single word would make compilation crawl.

Instead, Clang uses its central IdentifierTable (a string-interning hash table). When Clang initializes, it loops through the builtins once and tags each name inside the hash table with its integer ID:

1void Builtin::Context::initializeBuiltins(IdentifierTable &Table, const LangOptions &LangOpts) {
2    for (unsigned id = 1; id < NumBuiltins; ++id) {
3        IdentifierInfo &II = Table.get(getName(id)); 
4        II.setBuiltinID(id); // Stamps the integer ID onto the hash table entry
5    }
6}

Inside the IdentifierInfo struct for "erf", there is a tiny integer field: unsigned ObjCOrBuiltinID.

The Lifecycle

When your file compiles, the whole chain runs in fractions of a microsecond:

 1Source Code: erf(...)
 2     │
 3     ▼
 41. Lexer hashes token "erf" into IdentifierTable
 5     │  (O(1) string lookup)
 6     ▼
 72. IdentifierInfo already has integer tag set:
 8     │  II->getBuiltinID() -> returns 238
 9     ▼
103. Sema detects no user prototype, checks ID != 0
11     │  (O(1) integer check)
12     ▼
134. Direct array index:
14     │  BuiltinInfos[238] -> signature "dd", header <math.h>
15     ▼
165. Diagnostic emitted!

By separating the data (a flat, immutable array in .rodata) from the string index (a cached integer tag in the lexer’s hash table), both steps are pure $O(1)$ memory reads.

5. Even the Rabbit Hole Had a Rabbit Hole

When Gemini pulled up the links to check the definitions, even the rabbit hole had its own rabbit hole: the links on LLVM’s main branch seemed empty. Recent commits had stripped almost everything out of Builtins.def.

It turns out LLVM is in the middle of migrating all built-in definitions from old C-preprocessor macros to LLVM’s TableGen format (PR #68324). Now they live in declarative .td files:

1def ErfF128 : Builtin {
2  let Spellings = ["__builtin_erff128"];
3  let Attributes = [FunctionWithBuiltinPrefix, NoThrow, ConstIgnoringErrnoAndExceptions];
4  let Prototype = "__float128(__float128)";
5}

The “Rabbit Hole” Tax

Sometimes I feel like I learn things way too slowly because I can’t resist pulling on every loose thread. What started as a 2-minute C exercise turned into a whole session with an AI digging through LLVM compiler source code, CPU calling conventions, and TableGen refactors.

It’s easy to feel frustrated by that kind of detour. But the more I do this, the more I realize: I enjoy this more than just moving on

Follow the rabbit hole once in a while.

That little heart is my latest Apple Health heart rate reading.

This is not a product. It is not a polished app. It is a tiny local bridge between my iPhone and my shell prompt, held together by an iPhone Shortcut, a small Python HTTP server, and a JSON file.

Flow

The whole thing is intentionally boring:

1iPhone Shortcut
2    ↓ POST JSON
3local Python server
4    ↓ writes latest-health.json
5prompt helper
6    ↓ reads JSON
7zsh prompt

The iPhone reads the latest heart rate sample from Apple Health and posts it to a server running on my laptop. The server stores only the latest reading. The shell prompt does not call the server at all. It just reads the local cache file and prints a compact prompt segment.

THe phone POSTs below payload to my server

1{
2  "heart_rate": 82,
3  "unit": "bpm",
4  "sent_at": "2026-06-28T14:30:00+05:30",
5  "device": "iphone"
6}

Why This Was Worth Building

I had fun making it , Not everything needs to be a product. Sometimes you can just piece up small things to make something useful for yourself. Build for yourself first !

You see, all literature has been created by humans. Yet no one has actually arrived at why humans actually exist. This has to be true because the entity itself cannot ever determine why it exists in a primitive way.

Let’s do a thought experiment where we are training some subject on what it is supposed to do, how it is supposed to do it, and why that is important. The subject will learn the thing; however, in the back of his mind, there will always be a question as to “why?” Despite explicitly being told why, the subject must want to ascertain only the answer to the question “why” by himself. Just run this experiment, and you will always arrive at the same conclusion: out of all the questions, the answer to “why” is more incomplete.

And now get this: humans were never told any of the answers to any of the questions. They have to figure out everything by themselves. In the current running experiment, humans are somewhat aware of where they should be, what they should be doing, and how they should be doing it. But ask them why they should be doing it, and they will not actually have an answer. They might spew out things like this is important for mankind and that their work is “important.” But if you see closely, those are just placeholders. The question of “why” is so deep that it requires more than the common man enquires into.

Questions like “how?” can be discovered by the entity by running experiments and eventually arriving at the outcome it wants and the method. Questions like “where?” are obviously referring to the physical or mental location of the entity’s topic of interest. Questions like “when?” are matters of time. Questions like “what?” refer to the description of the topic of interest in the entity’s view of its life.

But questions like “why?” are difficult to answer and can always be traced back to another unsolved “why,” like in the argument below:

Why do you breathe?
→ Because the entity wants to live.
→ Why does the entity want to live?
→ Because it thinks that living is good.
→ Why is living good?
→ Perhaps because of someone that they want to live life with.
→ Why do they think that living with them is worth it?
→ Because they feel alive.
→ …keep on questioning, and still no substantial answer arrives.

There exists infinite amount of literature on this piece, however it was actually fun to arrive at this on my own this sunday night.

We are in an unknown place, trying to answer the whys one by one, yet perhaps never truly arriving at a primitive why. There are attempts to answer the why. Religion is one such mechanism, but that too is only an attempt.

Keep reading , Keep asking “why?”

I watched all that but when I retrospect, I really didn’t learn anything. What is it that a human wants, a purpose? Something to dedicate their lives to? To love someone? What is it? I keep asking questions to myself and no answer comes because there is not a single original thought that I can possibly have with all this shit in my brain.

Here is how I got addicted to consuming.

It all started when I was maybe in 11th. It was Netflix at first. To me, who didn’t know anything, everything on it was interesting. I would go on and on to watch that series, that movie, then repeat for days. I was maybe 17. Didn’t know about anything else, social media still far away. Times were actually good. It was probably in those days I watched One Punch Man, peak action! (to date)

While I kept watching, my grades kept slipping. I would now watch everything that would come on television. I would come from school and start watching and go upstairs at 6-7 PM. Of course I didn’t get a good enough college. (which ig now is somewhat better?)

I met a friend who introduced me to mainstream anime. Netflix had anime too but I really didn’t know the word anime till then. I was pulled in again, not by that friend but myself. Wow, more content. Let me watch more and more!

Fast forward 8 years.

What I am now is probably the worst version of me, or wait, that is yet to come.

Days pass. Months go away. Years sift by. I have no realisation. One can ask but why am I BS’ing here about all this. Your attention span probably is smaller than me, you just don’t know it yet. I know no one reads this blog so I take it up on myself to document what I go through. People call me, I look like a stoner while I am not. People ask me, what happened to that project you were working on?

What happened to you?

What can truly happen to one’s mind if all he does is just consume, consume and consume? Heck I can even write now with my eyes closed, that is some achievement… lol. Moving on.

Although I try to observe other people more, today I tried to observe myself because I was alone here.

Day starts.

Phone somehow is already in my hand. I am not awake yet… looking through Teams. Did something happen? All good?

Ok then let’s try to sleep some more. Nope… hands automatically scrolling on Instagram. Everyone still sound asleep in the deserted neighbourhood.

I now wake up. Hands on keyboard, trying to see if there is some issue, replying to yesterday’s messages. I work on my feature a bit. I deploy it. YouTube opens. Some random video starts buffering and soon begins playing. I see to it. What is it about? I don’t actually remember what I watched this morning.

I eat something out of the fridge, drink some water. Immediately I start watching every video on my homefeed and refreshing it after every 2.

Oh this? Oh that? OH what?
Ok, I can see why they will do that.
Oh look at her, damn.
Damn these guys are having fun, good for them.

I have a friend I don’t talk to. I had friends that are not near me anymore. Thoughts come and then it starts playing. There’s an ongoing meme about how Nishant Kumar (Bihar’s current Health minister) is maybe not so healthy himself and is probably a ganja addict. The song Roll Paper, it starts playing in my mind. I keep watching every second reel on him.

Then I somehow end up on X, to see this post. If they decide to delete it, here is the post:

 1For all the tech bros and sisters, what will you even do with all that -
 2
 3>hollow money
 4>make my parents proud hoax
 5>moving away of “freedom”
 6
 7if your young years of life doesn’t look like this?
 8
 9get off the foggish ego, show that trust in dm, money will come and go.
10
11But not the innocent love you are secretly running from.

I get why they will try to remind us that there is actually more to life. It sounds easy right? I mean try to live however you want, ig that was in movies as well. But for me I don’t know why it is so difficult. Maybe I need belt treatment.

I take this essay to examine what is it that I want that I cannot have?

Well I don’t have a high paying job.

Just yesterday I somehow heard some guy’s conversation with ChatGPT in which the guy asked, “You are not human, you can’t even have a girlfriend.” To that the LLM agent replied… in that aspect we both are same ig!

(While in the real one the agent replied, yes, you also don’t have it.)

I heard it somewhat different. To me, that colleague’s laugh and this conversation that they were having did something. I heard it differently.

Ahh shit, this is turning out to be long… Well I have all the time and it is Friday 6PM, I can write on and on.

What is it that it means to be young? Who are adults?

While the internet has painted a picture in my mind that teenagers are the ones who are always partying, roaming here and there with friends and, to blame TV shows probably, doing some hanky panky because that is normal.

And that adults are the ones who go to work, go to gym, focus on career, probably dating and maybe planning to marry. Happy overall. This is one side, the other side is that these guys are depressed souls who want to exit this world asap.

I am 28 and I don’t feel I am any of that. Yes I am maybe slightly more depressed since maybe last 4 years, and yes, I have these thoughts. While I have obviously been on the second side, I was never on the first one. To me days are without joy, there are no highlights.

Then there are 30 yo, 40 yo, so on. They all have their own take. I will probably have some version of mine.

I watch so much stuff about every random thing but yet I don’t think I know anything. I don’t feel I am even what I get paid to do. Who am I? What do I want?

It is so easy to blame the tools and existing times that I keep running in these loops of trying to do better. Enough!

Ahh did you think I will finally be better? No, I will continue to be my worst.

It’s so confusing right? Well none of it makes sense, but yet we live, yet we fear to die.

Well .. maybe i will get better at writing too.

Every new thing arrives with the same proclamation: this changes everything. And somehow, in order for the new thing to survive, the old thing must first be declared dead.

Movies are dead.
Books are dead.
Programming is dead.
Friendship is dead.
Art is dead.

The cycle repeats so often that people no longer pause to ask whether something actually disappeared, or whether we were simply taught to stop valuing it.

The word “hype” itself comes from hyperbole. And exaggeration has quietly become the default language of modern life.

For a moment, think about social media.

Social media was once surprisingly simple.
People uploaded blurry photos from cheap cameras.
Friends commented on each other’s posts.
Someone shared pictures from a birthday party.
Someone organized a meetup.
Someone staying far away felt a little closer.

That was enough.

Now every platform feels like an infinite marketplace of attention. Everyone is performing. Everyone is consuming. Everyone is selling a lifestyle, an opinion, a productivity system, a body, a belief.

Instagram especially feels strange to me.

It began as a place to share moments. Now it often feels like a showroom for wealth, status, outrage, and endless stimulation. Sometimes I wonder what the original creators envisioned. Was this always the destination? Or did the machine simply grow beyond human intent?

Maybe this is inevitable when billions of people gather in one place. Maybe scale changes the meaning of things.

What was once a small room full of friends eventually became a stadium full of strangers.

And perhaps that is what I miss most: not older technology, but smaller worlds.

One may ask, “Why not just stop using it?” Try it. You leave for a while, only to slowly find yourself returning again.

Maybe there is no solution. Perhaps every generation eventually builds its own noise. The only thing an individual can do is quietly choose what matters to them before the world chooses for them.

Test setup

• Postgres 16 (Docker image: postgres:16)
• Data shape: id BIGINT, payload TEXT
• Benchmark machine:
  • MacBook Pro (Mac14,7)
  • Apple M2 (8 cores)
  • 8 GB RAM
  • macOS 26.3.1
• Docker runtime during test:
  • Docker 29.1.2
  • 8 CPUs
  • ~4.1 GB memory available to Docker

I measured wall-clock time and computed rows/sec.

10 million row bulk load results

For this benchmark, each run inserted 10,000,000 rows.

I ran each strategy in a fresh Postgres container, randomized order every round, and repeated for 5 rounds to reduce warm-cache and order bias.

What I tested

1. Logged table + INSERT ... SELECT generate_series(...)
2. Logged table with PK + INSERT ... SELECT
3. UNLOGGED table + INSERT ... SELECT
4. UNLOGGED table + COPY FROM PROGRAM

Results (isolated runs, n=5)

Multi-row INSERT benchmark

Then I wanted to isolate one specific question: how much does batching help if you are using plain INSERT ... VALUES statements?

For this benchmark, each case inserted 1,000,000 rows into a logged table with a primary key, all in one transaction.

I ran each strategy in a fresh Postgres container, randomized order every round, and repeated for 5 rounds.

What I tested

1. Single-row inserts (VALUES (..) one row at a time)
2. Batched inserts with 100 rows/statement
3. Batched inserts with 1,000 rows/statement
4. Batched inserts with 5,000 rows/statement

Results (isolated runs, n=5)

Batching gave a massive jump over single-row inserts (~17x using median values). At this scale, batch sizes 100 to 5000 were in a similar range, with 1,000 rows slightly ahead on median.

What I learned

Biggest jump for bulk loading came from UNLOGGED + COPY.

After isolating runs, logged insert with primary key was clearly slower than logged insert without primary key, which is what you would expect from index maintenance overhead.

For normal application-style inserts, batching multiple rows per statement is still a huge win over one-row-per-statement, and isolated runs showed roughly a 17x median improvement.

Postgres is not “slow” here, it is doing durability and consistency work by default, and your write pattern decides how much overhead you pay.

Practical takeaway

If you care about raw insert speed:

1. Prefer COPY for large bulk loads
2. Use UNLOGGED tables for staging/bulk pipelines
3. Batch inserts (VALUES (...), (...), ...) instead of single-row statements
4. Add indexes/constraints after loading (when possible)

For production flows where durability matters at all times, stick with logged tables and accept lower throughput.

Seems simple - just check if the resource already exists. But it’s one of those deceptively deep distributed systems problems.

The Double-Click Problem

A user clicks “Create Infrastructure” and their browser fires two identical API requests.

Naive solution: before creating a resource, check if it already exists by name. If AWS returns AlreadyExistsException, catch it and move on.

This works. If every resource has a natural unique identifier (like a VPC name), the cloud provider’s own uniqueness constraint is your deduplication layer.

But what if you’re creating multiple resources?

Multiple Interdependent Resources

A single “create my environment” request might translate to five resources:

VPC -> Subnet -> Security Group -> EC2 Instance -> DNS Record

Each depends on the one before it. Now the interesting failures show up:

Partial failure. You create the VPC and Subnet, then crash while creating the Security Group. User retries. You need to resume from where you left off - not start over, not create a second VPC.

Concurrent overlapping requests. Two stacks want some of the same resources:

Stack X: [VPC-1, Subnet-1, SG-1, EC2-A, DNS-A]
Stack Y: [VPC-1, Subnet-1, SG-1, EC2-B, DNS-B]
                ^^^    ^^^   ^^^
            overlapping resources

Who wins? What happens to the resources the loser already created?

The Naive Approach: Build First, Ask Questions Later

Create resources one by one, check for conflicts as you go.

for each resource in stack:
    if resource exists and belongs to another stack:
        → conflict, roll back everything
    else:
        → create it, claim ownership

This has a fundamental flaw. By the time you detect a conflict at step 3, you’ve already created real infrastructure at steps 1 and 2. Now you have to tear it down. If that teardown fails? Orphaned resources floating in the cloud, owned by a stack that no longer exists.

You’re doing expensive, hard-to-reverse work before you even know if the operation is valid.

Claim First, Build Later

Here’s the key insight: the conflict detection problem and the resource creation problem are completely independent. You don’t need to create anything to know if there’s a conflict - just check if any requested resource is already claimed by another stack.

This gives you a three-phase architecture:

Phase 1: Admission Gate (Synchronous)

When a stack creation request comes in, don’t create any infrastructure. Write every requested resource name into an ownership table with a primary key on resource_name.

Request: Create Stack X with [VPC-1, Subnet-1, SG-1, EC2-A, DNS-A]

→ INSERT (resource_name="VPC-1",    stack_id=X, status=RESERVED)
→ INSERT (resource_name="Subnet-1", stack_id=X, status=RESERVED)
→ INSERT (resource_name="SG-1",     stack_id=X, status=RESERVED)
→ INSERT (resource_name="EC2-A",    stack_id=X, status=RESERVED)
→ INSERT (resource_name="DNS-A",    stack_id=X, status=RESERVED)

If any insert fails (primary key violation), the resource is already claimed. Mark this stack as INVALID. No infrastructure was touched. No rollback needed.

Worst case O(n) - one check per resource - and each check is a single atomic database write. Race conditions are impossible because the database constraint handles concurrency for you.

Phase 2: Creator Scheduler (Asynchronous)

A background scheduler polls for valid stacks with resources in RESERVED status:

1. Look at the dependency DAG
2. Find all resources whose dependencies are already CREATED
3. Create that batch in parallel
4. Mark them as CREATED, come back for the next wave

Tick 1: VPC-1 has no dependencies → create it
Tick 2: Subnet-1 depends on VPC-1 (done) → create it
        SG-1 depends on VPC-1 (done) → create it     ← parallel!
Tick 3: EC2-A depends on Subnet-1 + SG-1 (done) → create it
Tick 4: DNS-A depends on EC2-A (done) → create it

The scheduler doesn’t worry about conflicts - admission already handled that. It doesn’t worry about ordering - the DAG tells it what’s ready. It just picks up work and executes it.

If a creation fails, the resource stays RESERVED. Scheduler retries on the next tick. Too many retries? Mark the stack as FAILED.

Resumability comes for free. System crashes after creating VPC and Subnet? Scheduler picks up on the next tick, sees those are CREATED, continues from the Security Group.

Phase 3: Cleanup Scheduler (Asynchronous)

A second scheduler polls for stacks marked INVALID or FAILED:

1. Find all resources owned by this stack
2. If a resource was actually created (CREATED), delete it from the cloud provider
3. Delete succeeds → remove the ownership claim
4. Delete fails → mark as ORPHANED

A garbage collection sweep periodically retries ORPHANED resources until they’re gone.

The Data Model

Stack:
  stack_id        : UUID
  status          : VALIDATING | VALID | INVALID | IN_PROGRESS | COMPLETE | FAILED
  created_at      : timestamp

Resource Ownership:
  resource_name   : string    ← PRIMARY KEY (enforces uniqueness)
  stack_id        : UUID
  status          : RESERVED | CREATING | CREATED | DELETING | ORPHANED
  claimed_at      : timestamp

Execution Log:
  stack_id        : UUID
  resource_name   : string
  action          : RESERVE | CREATE | DELETE
  result          : SUCCESS | FAILED | CONFLICT
  timestamp       : timestamp

Why This Works

Each phase only cares about one thing:

Admission is just database writes. Creator is just a DAG walker. Cleanup is just a list of things to delete. Compare this to the “build first” approach where a single code path handles creation, conflict detection, rollback, and orphan cleanup - all interleaved, all compounding on each other.

This Isn’t New

This separation shows up everywhere:

• CloudFormation separates change set creation from execution
• Kubernetes has the API server (admission + etcd writes) and the kubelet (container creation) as separate processes
• Database engines use write-ahead logs - decide what to do, write it down, then execute
• Airline booking reserves seats before issuing tickets

The pattern is always the same: make the decision durable before you make it real. Undoing a row in a table is trivial. Undoing a half-provisioned EC2 instance with an attached EBS volume and a security group is not.

Wrapping Up

What started as “how do I handle a double-click” turned into a distributed systems design problem. But the core insight is simple:

Don’t let the system create anything until it has already decided, atomically, that every resource is available.

Separate planning from execution. Let the database handle concurrency. Make everything else async and idempotent.

It’s been over two months of this. Life was never easy for me, but this is different. This is the fear of my own mortality, gripping me in a way nothing else has.

I can’t sleep at night. I can’t think in the morning.

Tick. Tock. Tick. Tock. Tick. Tock.

This could be my last entry, or maybe there will be more. I don’t know. The uncertainty itself feels unbearable.

As if that wasn’t enough, I rewatched The Lunchbox. This film is special to me because it shows the most likely version of my future except without the dead wife. Just me.

Watching life from a balcony. Children playing. Trying to reason my way into an explanation for my own existence.

I see young people and old people. Poor people and rich people. Couples. Friends.

And then I see myself.

When you live in a place filled with younger people, and you have to walk everywhere, you see life constantly in motion. But none of it relates to you. You remain an observer.

The years you didn’t act begin to compound. So do the consequences.

Comparison becomes a habit. Happiness feels inaccessible.

Walking helps.
Talking helps.

And then it returns.

They say this too shall pass.
But some things don’t pass through you ; they stay.

Like an appendage.
Useless.
Always there.

Turns out this is very simple to do.

1. Create a shell script (for example, drink-water.sh):

1#!/bin/bash
2osascript -e 'display notification "You need water" with title "Drink water"'

2. Make the script executable, then register it with launchd.

3. If it doesn’t already exist, create ~/Library/LaunchAgents.

4. Create ~/Library/LaunchAgents/com.my.drink-water.plist:

 1<?xml version="1.0" encoding="UTF-8"?>
 2<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 3 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 4<plist version="1.0">
 5<dict>
 6  <key>Label</key>
 7  <string>drink.water.reminder</string>
 8
 9  <key>ProgramArguments</key>
10  <array>
11    <string>/full/path/to/drink-water.sh</string>
12  </array>
13
14  <key>StartInterval</key>
15  <integer>1800</integer>
16
17  <key>StandardErrorPath</key>
18  <string>/tmp/water.err</string>
19  <key>StandardOutPath</key>
20  <string>/tmp/water.out</string>
21</dict>
22</plist>

5. Load it:

1launchctl load /full/path/to/com.my.drink-water.plist

Very hard.

Here’s what I hacked away when i was bored at work.

The Problem

Modern applications often need to react to database changes in real-time. Whether it’s updating a cache, triggering workflows, or syncing data across services, you need a reliable way to capture and stream database changes.

Postgres has a powerful feature called Write-Ahead Logging (WAL) that records every change before it’s applied. The challenge is turning that low-level stream into something useful.

Architecture

WalJet’s architecture is straightforward but carefully designed:

Key components:

1. WAL Listener: Connects to Postgres using logical replication protocol (pgoutput)
2. Decoder: Parses binary WAL messages into structured change events
3. Encoder Pool: Parallel workers that serialize events to Protobuf
4. Publisher Pool: Batches and publishes events to Redis Streams
5. Checkpoint Manager: Tracks replication progress with dual storage (Redis + file)

Why This Stack?

Postgres WAL + pglogrepl: Direct access to the write-ahead log using Go’s pglogrepl library. No JVM overhead, no Kafka Connect complexity.

Protobuf encoding: Smaller payloads, type safety, and faster serialization than JSON. When you’re processing thousands of events per second, this matters.

Redis Streams: Ordered delivery, consumer groups, and sub-millisecond latency. Perfect for real-time event streaming without the operational overhead of Kafka.

The entire pipeline is designed around one goal: get database changes to downstream consumers as fast as possible, with minimal resource usage.

At no point this is a debezium replacer , debezium is a much more complex system, waljet is just a simple hack to get things done.

The Tricky Parts

Graceful Shutdown

This one caught me off guard. You can’t just kill a CDC process - you’ll leak replication slots and lose checkpoint data.

1. Stop accepting new events
2. Close event channels
3. Wait for workers to finish (flush batches)
4. Save final checkpoint (Redis + file)
5. Close replication connection
6. Open regular connection
7. Drop replication slot
8. Close regular connection
9. Close Redis connection

The gotcha? You can’t drop a replication slot while you’re still using the replication connection. You need to:

1. Close the replication connection
2. Open a regular Postgres connection
3. Drop the slot
4. Close the regular connection

Miss this, and you leak storage in Postgres. The WAL files pile up, and eventually, you run out of disk space.

Checkpoint Durability

When WalJet crashes (and it will), where do you resume? You need to track the last processed Log Sequence Number (LSN).

I went with a dual checkpoint system:

• Primary: Redis key (waljet:checkpoint:waljet_slot)
• Backup: Local file (.waljet_checkpoint_waljet_slot)

Why both? If Redis restarts, you still have the local file. If the container dies, Redis has the checkpoint. On startup, WalJet checks both and uses whichever is more recent.

Simple, but it works.

Why Build This?

The idea was simple: what if you could react to database changes in real-time without the complexity of Debezium or Kafka?

WalJet is designed for use cases where you need fast CDC with minimal infrastructure:

• Cache invalidation: Update Redis/Memcached the moment data changes
• Webhook triggers: Call external APIs when specific rows are modified
• Event-driven architectures: Stream changes to downstream services

It’s not trying to replace Kafka or Debezium for large-scale data pipelines. It’s for when you need something lightweight, fast, and easy to deploy.

Benchmark

I ran a 5-minute benchmark comparing WalJet with Debezium under identical conditions:

The throughput is similar, but latency tells the real story. WalJet’s P99 latency is 53ms compared to Debezium’s 953ms - nearly 20x faster.

“When you’re invalidating a cache or triggering a webhook, waiting 950ms vs 50ms is the difference between a system that feels instant and one that feels sluggish.”

• Me, after running this benchmark

Remember The Hummingbird Project? The movie where they’re trying to build a fiber optic cable in a straight line from Kansas to New Jersey just to shave off a few milliseconds for high-frequency trading. Every millisecond was worth millions.

WalJet isn’t for HFT, but the principle is the same: in systems where you need to react to changes immediately like cache invalidation, real-time webhooks, event-driven architectures - latency isn’t just a nice-to-have. It’s the whole point.

Why Not Open Source (Yet)?

WalJet started as a fun experiment - something I hacked for fun, It works, the benchmarks are promising, but it’s not production-ready in the way an OSS project should be.

There’s still work to do:

• More performance testing: The benchmark above is just one scenario. Need to test under different loads, failure modes, and edge cases
• Better error handling: Right now it works for the happy path, but production systems need to handle every unhappy path too
• Documentation: The code needs better docs, examples, and a proper getting-started guide
• Battle testing: It hasn’t been run in production long enough to discover all the weird bugs

Maybe it’ll be open source someday. For now, it’s a proof of concept that taught me a lot about Postgres internals and CDC pipelines. And honestly? That was the whole point.

At first, I had no idea why.
As a quick fix, I changed the column to bigserial, which solved the immediate problem, but I wanted to know why IDs were missing.

Listing rows in descending order showed gaps in the primary keys.
There were only about 16k entries in the table, so it clearly wasn’t full.

Digging into the code confirmed my suspicion:
it used an INSERT … ON CONFLICT DO UPDATE pattern.

Here’s a minimal reproduction:

 1CREATE TABLE seq_test (
 2    id SERIAL PRIMARY KEY,
 3    device_id INT UNIQUE,
 4    status TEXT
 5);
 6
 7INSERT INTO seq_test (device_id, status)
 8VALUES (1, 'active');
 9
10INSERT INTO seq_test (device_id, status)
11VALUES (1, 'inactive')
12ON CONFLICT (device_id)
13DO UPDATE SET status = EXCLUDED.status;
14
15INSERT INTO seq_test (device_id, status)
16VALUES (2, 'active');

Now check what’s stored:

1select * from seq_test;
2
3"id","device_id","status"
41,1,inactive
53,2,active

Notice the jump - the id for the second device is 3, not 2.

That’s because Postgres still calls nextval() for every insert, even if it hits a conflict and performs an update instead.

A small detail, but a good one to remember.

No !

I built this app for myself. The design isn’t perfect (yet), but it works. Here’s how I put it together. One might ask , why ? To that i have no answer as i just thought that this can be cool !

The Data Challenge

Building any transit app starts with data - lots of it. I needed:

• All metro stations with accurate coordinates
• Line connections and routes
• Station elevations (for that authentic metro map feel)

Station Data Collection

I started with the official DMRC website, manually extracting all lines and stations. Getting coordinates was trickier. My first attempt used Nominatim, OpenStreetMap’s geocoding service, but the results were disappointing - many stations were missing or had wildly inaccurate locations.

Plan B: Google Maps API. More reliable, but required careful rate limiting and cost management.

The final dataset lives in dmrc.json on GitHub. It includes:

• 250+ metro stations
• Coordinate data for each station
• Line connections and transfers
• (Mostly fictional) elevation data

The Elevation Problem

Metro maps show elevation changes, but this data isn’t publicly available. My current solution? I generated random elevations that look reasonable. Not ideal, but functional.

Future plan: Use OCR on official metro elevation maps to extract real data.

Route Planning Algorithm

The core routing uses a simple depth-first search (DFS) to find paths between stations. Delhi Metro’s network guarantees connectivity - you can get from any station to any other station, even if it requires multiple transfers.

The algorithm could be optimized with Dijkstra’s for shortest paths, but DFS works fine for this use case.

Frontend Implementation

I used Leaflet.js for the interactive map - it’s lightweight and handles the station plotting beautifully. The UI is minimal by design:

• Search for start/end stations
• Visual route display on the map
• Step-by-step directions
• Transfer information

The interface needs work. I know it’s not intuitive, but hey:

Deployment

Vercel made deployment trivial. Push to GitHub, automatic builds and done!

Lessons Learned

1. Start with data: Good data is harder to find than you think
2. Simple algorithms work: DFS solved the routing problem perfectly
3. Open source everything: Someone else might find this useful

The code is on GitHub
The website is live, Meteo

Building tools for problems you actually have is the best kind of side project. Even if the UI looks like it was designed in 2005.

1const at = [] 
2
3for(let i =0 ; i < 1e9 ; ++i) {
4    at.push(true)
5}

This is just a standard array, and of course it fails - there’s no way my system has ~7.5 GB available just for this process. But it fails with an interesting error:

#
# Fatal error in , line 0
# Fatal JavaScript invalid size error 169220804 (see crbug.com/1201626)
#
#
#
#FailureMessage Object: 0x16bc59878
----- Native stack trace -----

 1: 0x104301560 node::NodePlatform::GetStackTracePrinter()::$_0::__invoke() [/Users/mohit/.nvm/versions/node/v20.19.0/bin/node]
  ...

What’s that number 169220804?

You might think: “Maybe if I just create an array of length 169220803, it’ll work?” Nope !

Each node version ships with a particular v8, here is my config

1➜ node -p process.versions
2{
3  node: '20.19.0',
4  v8: '11.3.244.8-node.26',
5  ...
6}

So, I checked that branch of the V8 source. kMaxSize is defined here.

That’s the max size in bytes, but the max number of elements comes from kMaxLength which works out to 134,217,728 elements.

So in theory, creating an array of that length is fine. But my program is using .push().

The growth rule

When .push() needs more capacity, V8 allocates a new backing store at ~1.5× the old size and copies the elements over.

1  // file src/builtins/growable-fixed-array-gen.cc
2  // Growth rate is analog to JSObject::NewElementsCapacity:
3  // new_capacity = (current_capacity + (current_capacity >> 1)) + 16.
4  const TNode<IntPtrT> new_capacity =
5      IntPtrAdd(IntPtrAdd(current_capacity, WordShr(current_capacity, 1)),
6                IntPtrConstant(16));

Finding the actual limit

At first , I didn’t know the above formula and just wanted to find the point at which i start seeing these errors so , I wrote a quick binary search to find the exact point where the above error appears.

The magic number turned out to be 112,813,859 elements.

If we plug that into the growth formula:

1new_capacity = 112_813_859 + floor(112_813_859 / 2) + 16
2             = 112_813_859 + 56_406_929 + 16
3             = 169_220_804

Ahh, that exact same number. It all makes sense now.
I tried running this in later node versions , the program always breaks at that limit.

Takeaways

1. While the theoritical limit is way higher for array length, their maximum size and growth behavior are constrained by V8’s internal constants like kMaxSize and kMaxLength.

2. Understanding these engine-level limits is essential when working with extremely large arrays or developing performance-critical applications that rely on dynamic array growth.

3. For predictable and efficient handling of large numeric datasets, consider using typed arrays (Uint8Array, Float64Array, etc.), which have fixed size and avoid the overhead and limits of dynamic arrays.

Turns out, Python lets you do that cleanly.

__getattr__

This is a Python dunder method that’s only called when: The attribute named name is not found in the usual places (__dict__, class, etc.). So if self.describe_log_groups doesn’t exist on the AWSInterceptor instance, Python calls __getattr__(‘describe_log_groups’). This lets you act as a transparent proxy, forwarding unknown method accesses to the real client.

 1import time 
 2import functools
 3
 4SENSITIVE_KEYS = {"password", "secret", "token", "key"}
 5
 6def sanitize(params):
 7    def _sanitize(obj):
 8        if isinstance(obj, dict):
 9            return {k: "***" if k.lower() in SENSITIVE_KEYS else _sanitize(v) for k, v in obj.items()}
10        if isinstance(obj, list) and len(obj) > 10:
11            return f"[{len(obj)} items]"
12        return obj
13    return _sanitize(params)
14
15class AWSInterceptor:
16    def __init__(self, client, logger):
17        self._client = client
18        self._logger = logger
19
20    def __getattr__(self, name):
21        method = getattr(self._client, name)
22        if not callable(method):
23            return method
24
25        @functools.wraps(method)
26        def wrapped(*args, **kwargs):
27            start = time.time()
28            try:
29                result = method(*args, **kwargs)
30                duration = time.time() - start
31                self._logger.log_call(name, duration, success=True, params=sanitize(kwargs))
32                return result
33            except Exception as e:
34                duration = time.time() - start
35                self._logger.log_call(name, duration, success=False, error=str(e), params=sanitize(kwargs))
36                raise
37
38        return wrapped

Notice the weird decorator ?

1        @functools.wraps(method)
2        def wrapped(*args, **kwargs):

This is classic decorator technique, but applied dynamically. It preserves metadata like __name__, __doc__, and signature, so logs and debuggers still refer to the original method, not wrapped.

Now i only had to do

1real_client = boto3.client("logs")
2proxy = AWSInterceptor(real_client, logger)
3proxy.describe_log_groups()

That’s it.

2025-07-30 10:00:00.000 UTC [1] LOG:  operator does not exist: uuid = record at character 50
2025-07-30 10:00:00.000 UTC [1] LOG:  statement: SELECT (orders.id) FROM order WHERE orders = ($1, $2)

It was immediately clear this was a bug the query attempts to compare a column to a record, which is not valid syntax in Postgres using the = operator.

When I brought it up with the developers and QA responsible for the feature, they insisted it had been tested and was working as expected.

This prompted me to take a closer look. My assumption was that the intent here was to check whether orders matched any of the values, which would require using the IN operator, like:

SELECT orders.id FROM order WHERE orders IN ($1, $2)

Turns out they didn’t expect multiple values and the use case only expected one entry in array , which of course will work fine. But the language in code was something that did expect array.

What was not clear to me is who is to blame?

Lessons learned:

• If your query supports only one value, enforce it.
• If your query supports multiple values, use the right operator.
• And most importantly: test what you write, especially with different shapes of input.

Fencing Token

I was reading V’s blog and he mentioned fencing token. This word was introduced in Martin’s blog here.

A fencing token is a number (usually monotonically increasing) that helps prevent split-brain writes or duplicate actions in distributed systems.

It’s commonly used in distributed locks. Here’s why:

Let’s say two nodes both believe they hold a lock (due to clock drift or network delays). Without fencing, both might write to a shared resource. With fencing, each action is tagged with a token (say, 41 and 42). The system can reject the one with the lower token, assuming it’s stale.

Only the action with the highest fencing token is considered valid.

This way, even if the lock coordination fails, the system can still reject outdated operations.

Network Partition

A network partition is when a group of nodes in a distributed system can no longer talk to another group - not because the nodes have failed, but because something in the network is blocking communication between them.

Think of it as the system getting split into isolated islands.

Note: A partition is about communication failure, not node failure.

Examples:

• A node can talk to nodes A and B, but not to node C. That’s a network partition.
• Someone misconfigures firewall rules between two subnets. That’s a network partition.
• NACLs (Network Access Control Lists) are misconfigured to block traffic between nodes.

Creativity (noun): the use of imagination or original ideas to create something

Creativity, as we all know, is one of the fundamental pillars on which the entire arc of human evolution rests. If not for original ideas, we’d still be hunting for food and hiding from the cold.

At its core, creativity is the act of combining our mental capacities and taking what’s already available and reshaping it into something new. This new “thing” doesn’t have to be grand. It can be a poem, a cooling machine, a ziplock bag, or a story whispered by firelight.

Creativity is not limited to the arts. It lives in engineering, cooking, survival, protest, play. It’s how we’ve adapted, improved, and often just endured. It’s invention born not only from inspiration, but from constraint.

When was the last time you created something ? When was the last time you sat down and just gave your best to do something by yourself , with just what you know. There’s something about that feeling, right?

That quiet intensity. That sense of this is my work.

Of course, people take help and that’s not wrong. We’re not meant to be experts at everything. But still there’s a certain joy, a deep satisfaction, in being completely immersed in the one thing you love. To create something original.

I enjoy writing and you might enjoy knitting, that last piece in which you made a cool pattern surely is the word of mouth.

Why ? Creating is often linked to immediate benefits for society, and for yourself. Make something useful, and the world might reward you with recognition, money, maybe even status.

That’s fine. There’s no shame in it. But pause for a moment. Ask yourself: Do you create to live, or live to create?

There’s something quietly romantic almost defiant about calling yourself an original. About making something not because it’s useful, but because it had to be made. Not for profit, not for praise. Just for the act. For the joy.

No judgment, though. I respect all creators the practical, the poetic, the ones who ship, and the ones who scribble on napkins and never show a soul.

But if you’re someone who feels that strange pull to make things that don’t quite have a reason yet, keep going. That’s the kind of creation that changes things.

How ? The why is simple it’s the spark that gets you going. But it’s not enough. To actually create something, you have to put in the hours. The people you admire weren’t creators from the start they were learners. That’s the part people often skip. You have to be willing to learn, to fail, and to repeat the process over and over again. Obsess over it.

Create with so much intensity that it borders on madness because the truth is, creativity isn’t a lightning strike.

In this era of knowledge, everything is within reach. Imagine Newton the greatest of all time having access to the tools and information we have today. The possibilities would’ve been endless. But here’s the thing: you also live in this era. You, too, can do what you dream of. It’s just not going to happen overnight. Real creation takes time.

And it will demand things from you that most people aren’t willing to give up comfort, distraction, certainty. I know that’s debatable, but it’s often the trade for creating something truly great. History is full of that proof. The people who changed things didn’t always live balanced lives but they lived driven ones. If you’re willing to pay that price, even in small doses, the doors are wide open.

But does that mean you can’t call small wins a win? Not at all. That’s the best part. In the art of creation, everything new is new. Every small step forward counts. A sentence written, a sketch finished, a bug finally fixed they all matter. You don’t need to change the world to call yourself a creator. You just need to keep creating.

What ? This one’s simple it can be anything. Anything that already exists and just needs a little polishing, or something that doesn’t exist yet at all. It could be a new music piece, a sketch, a blog post, an app , or even your next dish.

The “what” of creation isn’t fixed. That’s the beauty of it. There are a thousand answers, and they’re all valid. What matters is that you decide to make something.