Performance and the User

A feature that works correctly but takes eight seconds to respond is not a working feature — it is a frustrating one. Performance is not a technical vanity metric. It is a direct measure of user experience: how long someone waits, whether a page loads before they give up, whether a mobile app drains their battery. Every performance decision is a decision about how you treat your users' time and resources.

Why Performance Degrades

Software slows down for identifiable, fixable reasons. Understanding the categories helps you find problems: Algorithmic complexity: a poorly chosen algorithm scales badly as data grows. An algorithm that takes O(n²) time — where n is the size of the input — might be fast enough for 100 items but take 100 times as long for 1000 items and 10,000 times as long for 10,000 items. Big-O notation is a tool for describing how the cost of an algorithm grows with input size. O(1) is constant (best), O(log n) grows slowly, O(n) grows linearly, O(n²) grows quadratically (often a problem at scale). Excessive I/O: reading from disk, querying a database, or making a network request is orders of magnitude slower than reading from memory. Code that makes N database queries in a loop (the 'N+1 query problem') instead of one batched query will slow down dramatically as N grows. Memory pressure: creating and discarding large numbers of objects forces the garbage collector (in managed languages) to run frequently. Holding large data sets in memory longer than necessary prevents other processes from using those resources. Blocking the main thread: in a browser, any long-running computation on the main thread freezes the user interface. While the main thread is busy, clicks, scrolls, and input are ignored — the page appears frozen.

AI-generated code and performance: AI tools tend to generate functionally correct code without considering performance at scale. Common patterns to watch for: Looping queries: the AI writes a loop that calls the database once per iteration instead of a single query that fetches all needed data. Redundant computation: the AI recomputes the same value multiple times inside a loop instead of computing it once before the loop. Naive sorting or searching: the AI applies O(n²) sorting algorithms or linear searches where a sorted structure and binary search would be O(n log n) and O(log n) respectively. Unbounded data loading: the AI loads all records from a database table when only the first 10 are needed — fine for 100 rows, catastrophic for 1,000,000. These are not signs that the AI is incompetent — they are signs that your prompt did not specify performance requirements. Specifying constraints in your prompt ('this must handle 10,000 records efficiently' or 'this runs in the browser on mobile') dramatically improves output.

Communicating Performance Requirements to an AI

The most effective way to get performant AI-generated code is to state your constraints explicitly. An AI asked to 'write a function to find duplicate emails in a list' will produce something that works. An AI asked to 'write a function to find duplicate emails in a list of up to 500,000 records, running server-side, with O(n) time complexity' will produce something that scales. Performance requirements to consider specifying: - Expected input size (how many records, users, events?) - Acceptable latency (must respond in under 200ms?) - Environment (browser on mobile? server with 512MB RAM?) - Concurrency (how many simultaneous users or requests?)