Hi-Stakes Systems

Why Dynamic array sizes are doubled in capacity?

Mamta Gelanee — Thu, 19 Feb 2026 18:30:12 GMT

In systems programming, the dynamic array (e.g., std::vector, ArrayList, or Python's list) is a fundamental tool. But have you ever paused to ask why these containers double their capacity when they run out of space?

It might feel like "wasting" memory, but the math reveals that doubling is the brilliant way to keep our most common operation append() performing at best speed.

The Performance Killer : Linear Growth ($+K$)

Suppose we decide to be "memory efficient" and grow our array by a fixed amount—say, 100 slots—only when we absolutely need to.

If we want to insert N elements, how many times do we have to copy data to a new memory location?

Initial State: You allocate a block of 100. You fill it up (Elements 1 to 100). Copies = 0.
The 101st Element: You have no room. You must allocate a new block of 200. You copy the 100 existing elements over.
The 201st Element: You are full again. You allocate a block of 300. You copy the 200 existing elements over.
The 301st Element: You allocate 400. You copy the 300 existing elements over.

The total work (W) is an arithmetic progression:

$$W = 100 + 200 + 300 + ... + (N - 100)$$

Factoring out the 100,

$$W = 100 \times (1 + 2 + 3 + \dots + \frac{N}{100} - 1)$$

Applying the Arithmetic Series Formula,

The sum of 1 to M is, The quadratic formula is $\frac{M(M+1)}{2}$. Here, $M \approx \frac{N}{100}$

$$W \approx 100 \times \frac{(\frac{N}{100})^2}{2}$$

Using the sum of an arithmetic series, this results in:

$$W \approx 100 \times \frac{N^2}{100^2 \times 2} = 100 \times \frac{N^2}{10000 \times 2} = \frac{N^2}{100 \times 2} = \mathbf{\frac{N^2}{200}}$$

In Big-O terms, this is $O(N^2)$ total work. If you divide that by N insertions, each individual append() costs $O(N)$. As your dataset grows, your application will get exponentially slower.

The Efficiency King: Geometric Growth($\times 2$)

Now let's look at the same $N$ where we start with 100 slots, using the Doubling method:

Initial State: Allocate 100. Fill them. Copies = 0.
The 101st Element: Double to 200. Copy 100.
The 201st Element: Double to 400. Copy 200.
The 401st Element: Double to 800. Copy 400.
The 801st Element: Double to 1600. Copy 800.

For N elements (where N is a power of 2), our copy operations look like this:

$$W = 100 \times (1 + 2 + 4 + 8 + \dots + \frac{N}{2}) = 100 \times (2^0 + 2^1 + 2^2 + 2^3 + \dots + 2^{k-1})$$

This is a geometric series where base is 2. A key property of this series is that the sum of all previous terms is always less than the next term. Specifically:

$$W \approx 100 \times \sum_{i=0}^{x} 2^i = 2^{x+1} - 1 \approx 100 \times \sum_{i=0}^{k-1} 2^i = 2^{k-1+1} - 1\approx 100 \times \sum_{i=0}^{k-1} 2^i = 2^{k} - 1$$

$$ W \approx 2^k \approx N-100$$

The Big Reveal: Amortized ($O(1)$)

To find the average cost of a single append, we take the total work and divide it by the number of elements:

$$\frac{Total\ Work}{Total\ Elements} = \frac{N - 1}{N} \approx 1$$

Even though some appends are "expensive" (the ones that trigger a resize), the vast majority are "cheap." On average, every append costs a constant amount of time, or as we call it in software world, $O(1)$

Memory vs. Speed: The Growth Factor ($\alpha$)

While doubling $\alpha = 2$ is the textbook standard, the specific multiplier can vary:

Factor of 2.0: Extremely fast, but because $1 + 2 + 4 < 8$, the memory allocator can never "reuse" the old chunks of memory you just left behind. They are always too small for the next jump.
Factor of 1.5: Used by many modern libraries (like libc++ or FBVector). Because $1.5$ is smaller, it allows the allocator to eventually "recycle" the memory from previous steps, improving cache locality and reducing fragmentation.

Strategy	Total Copies (N)	Avg. Append Cost	Memory Overhead
Linear (+100)	\approx N ^2	O(N) ~ Slow	Low
Geometric ( \times 2 )	\approx N	O(1) ~ Fast	Up to 50%

Final Thought

We don't double the array because we are greedy for RAM; we double it because it turns a quadratic performance disaster into a linear, predictable success. It is one of the most successful "space-time tradeoffs" in computer science.

From Code to Life: The Full Lifecycle of an Android Process

Mamta Gelanee — Tue, 13 Jan 2026 21:22:35 GMT

As Android developers, we spend most of our time in the IDE. But to build truly high-performance systems, we have to look past the UI and understand the Linux Kernel layers that govern how an app transitions from a static APK to a living process.

This journey is a delicate balance of security, resource efficiency, and aggressive hardware optimizations done by Android OS.

Installation: Constructing the Sandbox

At installation, Android assigns each app a unique Linux User ID (UID), establishing a secure sandbox through Discretionary Access Control (DAC). This is part of a broader 'Defense in Depth' strategy that strictly isolates the privileged Kernel (Ring 0) from the User Space (Ring 3). To prevent privilege escalation, Mandatory Access Control (MAC) via SELinux enforces a global security policy that blocks unauthorized requests at the kernel level—even if an app appears to have the correct UID permissions.

The Infrastructure: Zygote, the Template Master

Starting a mobile app from scratch is resource-intensive. To optimize performance, Android utilizes the Zygote, a 'template' process initialized during system boot. Instead of cold-starting every app, Zygote performs the heavy lifting once eg.

launches the Android Runtime (ART),
sets up the JNI &
pre-loads thousands of core framework classes and native libraries into memory.

The Launch Trigger: What Happens When User Tap on App Icon?

Intent Dispatch: The moment a user taps an icon, the Launcher sends an Intent to the ActivityTaskManagerService (ATMS) to request a new activity transition.
Process Audit: The ActivityManagerService (AMS) evaluates the request. If the app isn't already running in the background (a "Cold Start"), the system prepares to host a new process.
The Zygote Handshake: AMS sends a creation command through a Unix Domain Socket to the Zygote—the system's pre-warmed "Master Process".
The Birth (Forking): Zygote executes a fork() system call. In milliseconds, a child process is "born" as a perfect clone of Zygote, inheriting the pre-loaded ART (Android Runtime) and core framework libraries, allowing the app to launch almost instantly.

While fork() is efficient, it introduces significant Kernel-level overhead,

Context Switching: fork() is a synchronous operation so the Kernel must context switch out of the Zygote to perform allocation logic and then context switch in the new child process. These transitions between Ring 3 & Ring 0 consume critical milliseconds.
TLB Pollution: After a fork(), the CPU’s Translation Lookaside Buffer (TLB)—a fast cache for memory mappings—is often invalidated. This leads to a high TLB Miss rate, forcing the CPU to consult slower main memory tables.
Copy-on-Write (CoW): To save memory, the child process initially shares parent process - Zygote’s memory pages as "Read-Only".
Page Fault Stutters: The real cost emerges at runtime when the app's Main Thread modifies a shared page (e.g., creating an object), a Page Fault occurs when the Kernel must halt the app to physically copy that memory page in App's own process, causing unpredictable UI stuttering (Jank) during the first few seconds of launch.

Modern Architectural Optimisations

Android has introduced two major shifts to mitigate these hardware-level delays:

USAP (Unspecialized App Process): Introduced in Android 10, the USAP pool shifts the cost of fork() to system idle times. Zygote pre-forks several generic processes and keeps them in a pool. When an app is launched, the system simply "specialises" a USAP by giving it an identity, removing the ~25ms fork() latency from the user’s view.
16KB Memory Pages: Traditionally, the Kernel managed RAM in 4KB units. Modern Android versions support 16KB pages, Moving from 4KB to 16KB pages reduces the number of page entries the Kernel needs to track, decreasing metadata overhead by 75%. This improves the TLB Hit Rate, leading to about ~3.16% reduction in app launch times under memory pressure.

The Engineer’s Action Plan: Bridging Kernel to Code

Understanding that every app is a "Copy-on-Write" clone of the Zygote changes how we should approach optimization. Here is how to apply these kernel-level insights to your codebase,

1. Defer Initialization to Avoid "Page Fault Storms

Since the first few seconds of an app's life are plagued by Page Faults as the kernel physically copies memory pages, avoid heavy work in Application.onCreate() or static initializers.

Action: Use by lazy for heavy objects (e.g, Initialisations of Database, Analytics SDKs etc.).
Result: You move the "Physical Copy" cost away from the critical startup path, reducing UI jank.

2. Leverage Baseline Profiles

The Android Runtime (ART) can pre-compile your code into machine code, but it needs to know which paths are critical.

Action: Ship Baseline Profiles.
Result: This reduces the work the CPU has to do during the "specialization" phase, lessening the impact of TLB misses and instruction cache pressure.

3. Optimize for 16KB Page Sizes

With the move toward 16KB pages in modern Android, the way we handle native libraries is changing.

Action: Ensure your or third party native C/C++ libraries are aligned to 16KB boundaries.
Result: This significantly reduces the metadata the kernel must track. In memory-constrained scenarios, this optimization can reduce app launch times significantly.

The Golden Rule

Every byte you initialize at startup is a page you've forced the kernel to copy. Keep your startup footprint light, lazy, and profile-driven.

From Silicon to Screen

Mamta Gelanee — Mon, 05 Jan 2026 21:09:31 GMT

As Android engineers, we spend most of our time in the application layer. However, the smoothness of our UI is governed by hardware limitations and how the Linux kernel manages resources. To build high-performance apps, we must understand the journey from a CPU instruction to a pixel being drawn.

The Hardware Foundation: CPUs, Cores, and Threads

At the lowest level, your Android device is powered by a Central Processing Unit (CPU). The CPU is the entire chip package (the "socket"). In the early days, a CPU had only one core. Today, a single CPU is essentially a cluster of cores sharing a few high-level resources Cache, Internal Bus etc.

Cores: A core is an independent processing unit within the CPU. Modern mobile SoCs (System on Chips) usually follow a "Heterogeneous" architecture (like ARM’s big.LITTLE), mixing high-performance cores with power-efficient cores. So today when mobile phone has 8 cores that means it’s CPU has 8 separate processing units to run instructions physically in parallel at same time.
Threads (Software): While a Core is hardware (silicon), a Thread is a software/OS abstraction (short for "thread of execution") is the smallest unit of programmed instructions that can be executed independently by an Operating System scheduler. At a time then there is possibility of one or more threads running on a single core due to multi threading (operated by OS with techniques like time slicing) & Hyper Threading (Achieved by Hardware)

Now let’s get back to Android,

The "Main Thread" (The UI Thread)

When your app process starts, the system creates the Main Thread. This is the most "expensive" thread in your app because it has a monopoly on the UI Toolkit.

The Main Thread's Responsibilities:

Input Dispatching: Capturing touch events and key presses.
UI Rendering: Executing the Measure, Layout, and Draw passes of your View hierarchy.
Lifecycle Callbacks: Running onCreate, onStart, onResume, etc.

The Physics of Smoothness: 60 FPS and the 16ms Rule

Most mobile displays refresh at a rate of 60Hz (60 times per second). To provide a fluid experience, the Android system must generate a new frame every 16.66 milliseconds.

1000 milliseconds / 60 frame per second = 16.66 ms per frame

The Choreographer is the system component that coordinates this timing. It waits for a VSYNC signal from the display hardware and then tells the Main Thread: "You have 16ms to tell me what the next frame looks like."

When Things Go Wrong: Jank and ANR

If you give the Main Thread a task that takes too long, you hit two levels of failure:

Level 1: Jank (Dropped Frames)

If a task (like a heavy loop or complex layout calculation) takes 20ms, the Main Thread misses the 16.66ms deadline. The Choreographer cannot draw the frame on time, so the previous frame stays on the screen. The user perceives this as a "stutter" or Jank.

Level 2: ANR (Application Not Responding)

If the Main Thread is blocked for a significant period—typically 5 seconds for an input event—the system triggers an ANR. The OS assumes the app has hung and gives the user a dialog to force-quit.

The Solution: Background Threads

To protect the Main Thread, we offload "Heavy" or "Blocking" tasks to Background Threads (Worker Threads).

Blocking Operations: Networking (Retrofit), Database queries (Room), or heavy Image Processing.
Modern Implementation: In modern Android, we use Kotlin Coroutines with Dispatchers.IO (for I/O tasks) or Dispatchers.Default (for CPU-intensive calculations).

Summary Checklist for Android Engineers

Respect the 16ms budget: Keep onDraw and onLayout lean.
Offload to Background: If it involves a disk, a network, or a complex loop, it doesn't belong on the Main Thread.
Profile your app: Use the Android Studio Profiler to visualize thread activity and identify "Janky" frames.

By mastering hardware foundations and the Main Thread's role in UI rendering, developers can optimize app performance. Adhering to the 16ms frame budget and using background threads for heavy tasks prevent jank and ANR issues. Following these principles and using tools like the Android Studio Profiler ensures a seamless user experience.

For more dee dive, feel free to follow this holy grail!