How to Optimize (Almost) Anything: A Systemized Framework

Optimization as a Repeatable Engineering Loop

Optimization is often romanticized in software development as a dark art—a realm where lone geniuses stare at assembly code until they hallucinate a 50% speedup. In reality, reliable performance engineering is far more mundane and far more effective. It is a disciplined, repeatable loop of measurement, hypothesis, and validation. Whether you are squeezing a AAA rendering pipeline into a 16ms frame budget or trying to reduce latency in a high-frequency trading algorithm, the underlying principles remain constant: you cannot optimize what you do not measure, and you cannot measure what you do not understand.For game developers and real-time graphics engineers, the stakes are binary: you either hit your frame target, or you don't. A game running at 29 frames per second on a 60Hz display isn't "almost there"—it's a failure that manifests as visible stutter and input lag. To solve this, we must move beyond ad-hoc "tweaking" and adopt a rigorous framework. This means treating performance not as a feature to be added at the end, but as a constraint to be managed from the beginning. It involves understanding the physical reality of your hardware—how the CPU predicts branches, how the GPU consumes command buffers, and why a cache miss costs you more time than hundreds of arithmetic instructions.This deep dive explores a comprehensive optimization framework derived from the insights of SimonDev. It deconstructs the optimization process into actionable stages: establishing strict budgets, profiling to find the truth, exploiting hardware parallelism, and finally—when physics gets in the way—learning how to "cheat" intelligently. By following this roadmap, we transform optimization from a panic-induced crunch activity into a systematic engineering practice.

Source and Scope

Video Metadata

This guide serves as a structured roadmap through the optimization lifecycle. We begin by defining the "definition of done" through strict budgeting, ensuring we know exactly how many milliseconds we can spend per frame. We then move to diagnosis, using profilers to distinguish between CPU and GPU bottlenecks. The middle sections focus on execution: harvesting "low-hanging fruit" like draw call reduction, restructuring data for cache locality, and vectorization. Finally, we explore the "dark arts" of graphics programming—culling, Level of Detail (LOD), and imposters—where we trade correctness for speed without the user noticing. The journey concludes with stability, ensuring that our average performance doesn't hide unacceptable worst-case spikes.

Video Arc and Key Takeaways

The video follows a logical progression from chaos to order. It begins with a naive, unoptimized scene of thousands of trees running at a crawl, and systematically applies optimization layers to achieve a high-performance result. The narrative shifts from basic code cleanup to architectural changes (Data-Oriented Design), then to algorithmic improvements (Culling), and finally to perceptual tricks (Imposters). This arc demonstrates that optimization is rarely about one "magic fix" but rather a sequence of compounding gains.Core Optimization Principles:

• Quantify "Fast" (1:21–1:52): Performance is not a feeling; it is a math problem. You must define a millisecond budget (e.g., 16.6ms for 60FPS) and treat it as a hard limit for all subsystems combined.
• Profile Before You Code (2:20–3:48): Never guess where the bottleneck is. Use tools (like VTune, Nsight, or browser profilers) to determine if you are CPU-bound or GPU-bound before changing a single line of code.
• Top-Down vs. Bottom-Up (2:51–3:19): Use top-down analysis to find which systems (e.g., "Physics") are slow, and bottom-up analysis to find which specific functions (e.g., "MatrixMultiply") are hot across the entire codebase.
• Reduce Draw Calls First (5:19–5:51): The CPU often chokes on submitting commands to the GPU. Techniques like batching and GPU instancing can increase rendered object counts by orders of magnitude.
• Respect the Hardware (6:19–8:24): Hardware loves contiguous memory and predictability. Random memory access causes cache misses, which can be hundreds of times slower than arithmetic operations.
• Predictability is Speed (8:24–10:00): Branch prediction failures flush the CPU pipeline. Sorting data to keep "true" and "false" branches together allows the CPU to speculate and execute ahead effectively.
• The "Speed of Light" Limit (12:08–12:30): Every system has a theoretical maximum performance. Once you approach this limit, stop optimizing the code and start optimizing the workload (do less work).
• Cheat Legitimately (14:47–16:40): If the player cannot see the difference, the "error" doesn't exist. Use LODs, imposters, and fog to reduce fidelity where it doesn't matter (e.g., distant objects).
• Target the Worst Case (17:35–18:24): Average FPS is a vanity metric. Stability is what matters. Design dynamic systems that scale down quality during chaos (e.g., explosions) to maintain a steady frame rate.

Step 1 — Turn ‘Fast’ into a Budget

The first step in any optimization task is to define the target. "Make it faster" is not a valid engineering goal because it has no completion criteria. Instead, we must speak in terms of frame budgets. A frame budget is the total time available to generate one distinct image on the screen. This is derived directly from your target refresh rate.For a standard 60 FPS target, the math is simple: $$1000ms / 60 = 16.66m$$. You have exactly 16.6 milliseconds to process user input, run game logic, simulate physics, update animation skeletons, issue drawing commands, and have the GPU render the pixels. If you miss this window, the frame is dropped, and the user perceives a hitch. For a 30 FPS target, you have a more luxurious 33.33ms, whereas a high-end 120 FPS target tightens the noose to just 8.33ms.

Crucially, this budget is shared. As shown in Figure 1, your "trees" don't get the full 16ms. They share that space with UI, audio, networking, and post-processing. If your vegetation system takes 4ms, that leaves only 12ms for the entire rest of the game. This zero-sum perspective forces difficult prioritization decisions early in development.Furthermore, we must distinguish between the CPU budget and the GPU budget. These two processors run in parallel (mostly). If your CPU takes 20ms to prepare the frame, but the GPU only takes 5ms to draw it, you are CPU-bound and running at ~50 FPS. Conversely, if the CPU is done in 2ms but the GPU takes 25ms to render the 4K textures, you are GPU-bound. Understanding which timeline is your limiting factor is the prerequisite for step 2.

Step 2 — Use a Profiler to Shrink the Problem

Intuition is a terrible guide for performance. Developers often optimize code they "feel" is slow, only to discover it contributed less than 1% to the total frame time. The only antidote is profiling. A profiler acts like an X-ray for your application, showing exactly where time is being spent.Effective profiling typically combines two methodologies:

• Top-Down Analysis: Starts from the main loop and drills down. You see that `GameLoop` calls `UpdateWorld`, which calls `PhysicsSystem`, which is taking 50% of the frame. This helps you identify which systems are misbehaving.
• Bottom-Up Analysis: Aggregates time by function, regardless of where it's called. You might find that `Vector3.Normalize()` is responsible for 10% of total execution time because it's being called 2 million times across physics, AI, and rendering. This identifies hot functions that yield global benefits when optimized.

In the scenario shown in Figure 2, the profiler reveals a classic CPU bottleneck. The CPU is spending all its time issuing draw commands (`drawArrays` or similar), while the GPU timeline shows gaps or low utilization. This confirms that making the shaders faster would be useless; the GPU is already waiting for the CPU. We must reduce the CPU overhead of submitting work.

Minimum Viable Profiling Workflow

1. Reproduce: Create a consistent test case (e.g., "Camera at position X looking at Y").
2. Capture: Record a frame trace using your tool of choice (Chrome DevTools, Superluminal, RenderDoc).
3. Identify Bound: Check if frame time is dominated by CPU or GPU.
4. Isolate: Find the specific function or draw call taking the most time.
5. Hypothesize: Formulate a fix (e.g., "Batch these calls").
6. Verify: Apply the fix and re-profile to confirm the gain.

Step 3 — Grab the Low-Hanging Fruit (and Expect Bottleneck Shift)

Once the profiler has identified the bottleneck, we look for "low-hanging fruit"—optimizations that yield massive gains for relatively little architectural effort. In the context of rendering thousands of trees, the most common culprit is draw call overhead.Every time you tell the API to "draw this mesh," the driver performs validation, state checking, and command buffer writing. If you draw 10,000 trees individually, the CPU spends more time talking to the driver than the GPU spends drawing the trees. The solution is GPU Instancing. This technique tells the GPU: "Here is one mesh, and here is a buffer containing 10,000 positions. Draw it 10,000 times."

As seen in Figure 3, the results are often dramatic. We moved from ~800 trees to ~30,000 trees, and the CPU usage (yellow graph) flatlined. However, notice what happened: the bottleneck shifted. The CPU is now bored, but the GPU is likely fully saturated processing vertices and pixels. This is a sign of success. You have cleared the administrative overhead and are now limited by raw throughput.Decision Heuristics:

• High CPU / Low GPU: Prioritize batching, instancing, and reducing driver overhead. Check logic update times.
• Low CPU / High GPU: Prioritize reducing vertex counts, texture sizes, shader complexity, or overdraw.
• High CPU / High GPU: You have too much of everything. Scale back the scene complexity globally.

Step 4 — Optimize the Input: Hardware-Friendly Data Layouts

After fixing obvious API inefficiencies, we must look deeper at how our data is structured in memory. Modern hardware has a strong preference: it wants contiguous memory and predictable access patterns. This is due to the latency gap between the CPU and main RAM. Fetching data from RAM is exponentially slower than fetching it from the L1 or L2 cache.When you store game objects as an "Array of Structures" (AoS)—typical in Object-Oriented Programming (e.g., `class Tree { pos, mesh, health }`)—processing them often involves jumping around heap memory. Each jump to a random address risks a Cache Miss.

To optimize for the hardware, we adopt Data-Oriented Design (DOD). Instead of an array of objects, we use a "Structure of Arrays" (SoA). We pack all positions into one contiguous array, all health values into another. When the CPU iterates over positions to update physics, it loads a cache line and finds the next 15 positions already there, waiting. This eliminates the latency of fetching data from RAM.Furthermore, predictable data layouts assist Branch Prediction. The CPU tries to guess the result of an `if` statement to execute ahead. If your data is random (e.g., sorted randomly), the CPU will mispredict often, forcing it to flush its pipeline and start over. If you sort your data (e.g., all "active" entities first), the branch becomes predictable, and execution flies.

As shown in Figure 5, contiguous data also unlocks SIMD (Single Instruction, Multiple Data). Because the data is aligned, the compiler (or you) can use vector instructions to update 4, 8, or 16 entities in a single CPU cycle. This is the architectural reason behind the rise of Entity Component Systems (ECS) in engines like Unity (DOTS) and Bevy. ECS enforces this hardware-friendly data layout by default, decoupling data from logic to maximize throughput.

Step 5 — When You Hit the ‘Speed of Light’: Three Routes Forward

Eventually, you will hit a wall. You have instanced your draws, linearized your memory, and vectorized your math. Your code is executing as fast as the silicon allows. This is the "speed of light" for your current workload. To go faster, you must change the rules. There are three fundamental routes to traverse this barrier:

The Optimization Triad

Route A: Do the Same Work, Faster

• Strategy: Code optimization, assembly tuning, better algorithms.
• Limit: Hard hardware limits (bandwidth, FLOPS).
• Example: Replacing a Bubble Sort with Quick Sort; using SIMD.

Route B: Do Less Work

• Strategy: Culling, spatial partitioning, sleep systems.
• Limit: Scene complexity and viewpoint.
• Example: Not drawing objects behind the camera (Frustum Culling).

Route C: Make it Look the Same, But Cheaper (Cheat)

• Strategy: Approximation, LODs, baking, imposters.
• Limit: Perceptual quality and artifacting.
• Example: Replacing a distant 3D tree with a 2D sprite.

Routes B and C are often where the biggest gains lie in mature projects. They focus on "workload optimization" rather than "code optimization."

Step 6 — Only Render What You Can See: Culling and World Structure

The most effective optimization is to strictly avoid processing anything that doesn't contribute to the final pixel color. This is the domain of culling. The primary form is Frustum Culling: determining if an object is inside the camera's field of view. If a tree is behind the player, sending it to the GPU is a waste of bandwidth.

To do this efficiently, we cannot iterate over every object in the world to check if it's visible (that's O(N)). Instead, we use Spatial Partitioning structures like Quadtrees, Octrees, or Bounding Volume Hierarchies (BVH). These allow us to reject entire chunks of the world at once. "Is this whole mountain sector behind the camera? Yes? Then ignore all 5,000 trees inside it."Common Pitfalls:

• Culling Overhead: The culling check itself takes CPU time. If your spatial structure is too fine-grained (e.g., checking every blade of grass), the check might cost more than just drawing the object.
• Occlusion Culling: Frustum culling doesn't help if you're looking at a wall with a city behind it. The city is "in the frustum" but blocked. Occlusion culling solves this but is complex and expensive to compute in real-time.

Step 7 — LOD, Imposters, and the Ethics of ‘Cheating’

In game development, "cheating" is not a moral failing; it is a professional requirement. Players do not care if your simulation is accurate; they care if it looks accurate. This gives us license to degrade quality based on distance and attention. This is formalized as Level of Detail (LOD).For a tree 10 meters away, we render the full 10,000-triangle mesh. At 100 meters, we swap it for a 1,000-triangle version. At 1,000 meters, we might render a simple "imposter"—a 2D billboard (quad) that always faces the camera. This reduces vertex load by 99.9% for distant objects.

Advanced techniques like Octahedral Imposters (Figure 8) take this further by baking 3D views of the object into a texture atlas. As the camera moves around the billboard, the shader interpolates between these views, giving the illusion of 3D depth and lighting response without the geometry cost.

Safe Cheating Checklist

• Distance Fog: Hide the transition to low-quality LODs behind a veil of atmosphere (the "Silent Hill" trick).
• Loading Corridors: Use slow elevators or narrow crevices to mask asset streaming (the "Mass Effect" trick).
• Bake Lighting: Pre-calculate complex lighting into static textures rather than computing it every frame.
• Aggressive Culling: Despawn or freeze logic for entities that are far away, not just their rendering.
• Resolution Scaling: Render 3D scene at 70% resolution and upscale UI at 100%.
• Time-Slicing: Update distant AI or animation only every 2nd or 4th frame.

Step 8 — Make It Stable: Control Worst-Case Behavior

A game that runs at 60 FPS most of the time but drops to 10 FPS during an explosion is a bad game. Players are far more sensitive to frame time variance (stutter) than to a slightly lower average frame rate. Optimization must therefore focus on smoothing the worst-case peaks.Consider a particle system. If ten explosions go off simultaneously, a naive system might spawn 10x the particles, causing massive overdraw and tanking the GPU. A robust system uses a global budget. If the budget allows 10,000 particles and you request 20,000, the system should dynamically throttle the density of each explosion. The player sees "lots of chaos" in both cases, but the throttled version maintains a stable framerate.

Targets

Team-Ready Optimization Checklist

• Define Min-Spec Early: Explicitly identify the lowest-end target hardware (e.g., "iPhone 11", "Intel HD 630", "Base PS4") and acquire these devices for daily testing. Optimization is meaningless without a baseline constraint.
• Strict Millisecond Budgets: Break the frame budget down by subsystem. For a 16.6ms target, allocate specific slices (e.g., "Rendering: 8ms", "Game Logic: 4ms", "Physics: 2ms", "UI: 1ms", "Headroom: 1.6ms").
• Asset Limits: Establish hard limits for artists and designers regarding texture memory, polygon counts per character, and audio bank sizes to prevent "death by a thousand assets."
• Degradation Strategy: Agree on acceptable quality tradeoffs for low-end devices (e.g., "Shadows are disabled on mobile", "Particles are halved on Switch") before production begins.

Baseline

• Performance Gym: Create a dedicated, deterministic test scene with fixed camera paths, lighting, and actor counts. This isolates code performance from level design fluctuations.
• Clean Environment: Ensure benchmarking machines have thermal throttling disabled, VSync off, and background applications (Discord, Chrome) closed to minimize noise.
• Gold Master Traces: Capture and store "Gold Standard" profiling traces of the Performance Gym running at target FPS. Use these as the ground truth for detecting future regressions.
• Automated Launch Configs: Use scripts to launch the game with identical resolution, window mode, and quality settings every time to guarantee apple-to-apples comparisons.

Tooling

• In-Engine Profiling: Integrate lightweight, always-available profilers (like Unity Profiler or Unreal Insights) into the daily workflow of every engineer, not just the tech lead.
• Deep Dive Tools: Ensure the team has access to and training on platform-specific capture tools (RenderDoc, Nsight Graphics, XCode Instruments) for inspecting GPU pipelines.
• On-Screen Debug Specs: Implement a toggleable debug overlay showing real-time FPS, Frame Time (ms), Draw Call counts, and Memory usage (System/Video) for immediate QA feedback.
• Remote Profiling: Verify that profiling tools can connect to and capture data from actual development kits (consoles/mobile) over the network, as the editor profiler is often misleading.

Diagnosis

• The Golden Rule: Never optimize without a trace. If you cannot demonstrate the bottleneck on a graph, you are guessing.
• Identify the Bound: Conclusively determine if the frame is waiting on the Main Thread (Logic), Render Thread (Submission), or GPU (Execution). Optimizing the wrong pipeline yields zero FPS gain.
• Top-Down Analysis: Identify which major systems (AI, Physics, Animation, UI) are blowing their budgets before drilling into specific functions.
• Hot Path Analysis: Use sampling profilers to find "death by a thousand cuts"—small, frequent functions (like `String.Format` or vector math) that accumulate to milliseconds of overhead.

Fixes

• CPU & Memory: Prioritize Data-Oriented Design. Linearize data structures to maximize cache hits and remove garbage collection pressure by pooling objects.
• Draw Calls: Aggressively batch geometry and utilize GPU Instancing. The fastest draw call is the one you bundle with 10,000 others.
• Culling: Implement robust Frustum and Occlusion Culling. If the camera can't see it, the CPU shouldn't submit it, and the GPU shouldn't render it.
• LODs & Imposters: Use Level of Detail systems to reduce geometric complexity over distance. Replace distant 3D meshes with 2D billboards (imposters) to save vertex processing.

Verification

• Re-Profile: Run the exact same test scenario after the fix. Quantify the gain (e.g., "Reduced Shadow Pass from 4.2ms to 2.1ms").
• Visual Regression Check: Perform A/B testing (toggle the fix on/off) to ensure the optimization didn't break lighting, physics behavior, or texture quality.
• Min-Spec Validation: Verify the performance gain on the target low-end hardware. An optimization that saves 0.1ms on a PC might save 2ms on a mobile device (or break it entirely).
• Peer Review: Ensure the optimized code remains readable and maintainable. Do not accept "clever" assembly hacks if a clean algorithm change yields 90% of the benefit.

Regression

• Automated Perf Tests: Integrate performance tests into the CI/CD pipeline. Have a dedicated machine run the Performance Gym scene nightly.
• Budget Enforcement: Configure the build system to fail if critical metrics are exceeded (e.g., "Build fails if Main Menu load time > 5s" or "Texture memory > 2GB").
• Trend Analysis: Graph performance metrics over time (e.g., Grafana, Jenkins) to spot "creeping" performance rot that is too small to notice in a single commit.
• Smoke Tests: Run quick asset validation scripts on import to reject assets that violate technical standards (e.g., 4K textures for small props) before they enter the repository.

Production Monitoring

• Telemetry: Collect anonymous frame rate histograms from real-world players. "Average FPS" is useless; track the "1% Lows" to understand the stutter experience.
• Crash & OOM Reporting: Monitor crash reports for Out-Of-Memory (OOM) errors, which often indicate memory leaks or asset budget violations in the wild.
• Hardware Stats: Aggregate data on user hardware (GPU model, RAM, CPU cores) to validate your Min-Spec assumptions and adjust optimization priorities for the live game.
• Spike Alerts: Set up automated alerts for new versions. If the "Crash Rate" or "Average Frame Time" spikes after a patch, roll back immediately.

Targets

Team-Ready Optimization Checklist

• Define Min-Spec Early: Explicitly identify the lowest-end target hardware (e.g., "iPhone 11", "Intel HD 630", "Base PS4") and acquire these devices for daily testing. Optimization is meaningless without a baseline constraint.
• Strict Millisecond Budgets: Break the frame budget down by subsystem. For a 16.6ms target, allocate specific slices (e.g., "Rendering: 8ms", "Game Logic: 4ms", "Physics: 2ms", "UI: 1ms", "Headroom: 1.6ms").
• Asset Limits: Establish hard limits for artists and designers regarding texture memory, polygon counts per character, and audio bank sizes to prevent "death by a thousand assets."
• Degradation Strategy: Agree on acceptable quality tradeoffs for low-end devices (e.g., "Shadows are disabled on mobile", "Particles are halved on Switch") before production begins.

Baseline

• Performance Gym: Create a dedicated, deterministic test scene with fixed camera paths, lighting, and actor counts. This isolates code performance from level design fluctuations.
• Clean Environment: Ensure benchmarking machines have thermal throttling disabled, VSync off, and background applications (Discord, Chrome) closed to minimize noise.
• Gold Master Traces: Capture and store "Gold Standard" profiling traces of the Performance Gym running at target FPS. Use these as the ground truth for detecting future regressions.
• Automated Launch Configs: Use scripts to launch the game with identical resolution, window mode, and quality settings every time to guarantee apple-to-apples comparisons.

Tooling

• In-Engine Profiling: Integrate lightweight, always-available profilers (like Unity Profiler or Unreal Insights) into the daily workflow of every engineer, not just the tech lead.
• Deep Dive Tools: Ensure the team has access to and training on platform-specific capture tools (RenderDoc, Nsight Graphics, XCode Instruments) for inspecting GPU pipelines.
• On-Screen Debug Specs: Implement a toggleable debug overlay showing real-time FPS, Frame Time (ms), Draw Call counts, and Memory usage (System/Video) for immediate QA feedback.
• Remote Profiling: Verify that profiling tools can connect to and capture data from actual development kits (consoles/mobile) over the network, as the editor profiler is often misleading.

Diagnosis

• The Golden Rule: Never optimize without a trace. If you cannot demonstrate the bottleneck on a graph, you are guessing.
• Identify the Bound: Conclusively determine if the frame is waiting on the Main Thread (Logic), Render Thread (Submission), or GPU (Execution). Optimizing the wrong pipeline yields zero FPS gain.
• Top-Down Analysis: Identify which major systems (AI, Physics, Animation, UI) are blowing their budgets before drilling into specific functions.
• Hot Path Analysis: Use sampling profilers to find "death by a thousand cuts"—small, frequent functions (like `String.Format` or vector math) that accumulate to milliseconds of overhead.

Fixes

• CPU & Memory: Prioritize Data-Oriented Design. Linearize data structures to maximize cache hits and remove garbage collection pressure by pooling objects.
• Draw Calls: Aggressively batch geometry and utilize GPU Instancing. The fastest draw call is the one you bundle with 10,000 others.
• Culling: Implement robust Frustum and Occlusion Culling. If the camera can't see it, the CPU shouldn't submit it, and the GPU shouldn't render it.
• LODs & Imposters: Use Level of Detail systems to reduce geometric complexity over distance. Replace distant 3D meshes with 2D billboards (imposters) to save vertex processing.

Verification

• Re-Profile: Run the exact same test scenario after the fix. Quantify the gain (e.g., "Reduced Shadow Pass from 4.2ms to 2.1ms").
• Visual Regression Check: Perform A/B testing (toggle the fix on/off) to ensure the optimization didn't break lighting, physics behavior, or texture quality.
• Min-Spec Validation: Verify the performance gain on the target low-end hardware. An optimization that saves 0.1ms on a PC might save 2ms on a mobile device (or break it entirely).
• Peer Review: Ensure the optimized code remains readable and maintainable. Do not accept "clever" assembly hacks if a clean algorithm change yields 90% of the benefit.

Regression

• Automated Perf Tests: Integrate performance tests into the CI/CD pipeline. Have a dedicated machine run the Performance Gym scene nightly.
• Budget Enforcement: Configure the build system to fail if critical metrics are exceeded (e.g., "Build fails if Main Menu load time > 5s" or "Texture memory > 2GB").
• Trend Analysis: Graph performance metrics over time (e.g., Grafana, Jenkins) to spot "creeping" performance rot that is too small to notice in a single commit.
• Smoke Tests: Run quick asset validation scripts on import to reject assets that violate technical standards (e.g., 4K textures for small props) before they enter the repository.

Production Monitoring

• Telemetry: Collect anonymous frame rate histograms from real-world players. "Average FPS" is useless; track the "1% Lows" to understand the stutter experience.
• Crash & OOM Reporting: Monitor crash reports for Out-Of-Memory (OOM) errors, which often indicate memory leaks or asset budget violations in the wild.
• Hardware Stats: Aggregate data on user hardware (GPU model, RAM, CPU cores) to validate your Min-Spec assumptions and adjust optimization priorities for the live game.
• Spike Alerts: Set up automated alerts for new versions. If the "Crash Rate" or "Average Frame Time" spikes after a patch, roll back immediately.

Conclusion and Next Steps

Optimization is a mindset, not a milestone. It requires shifting from "making it work" to "making it work efficiently." By adhering to a framework—budgeting, profiling, architectural alignment, and creative approximations—you can systematically dismantle performance barriers.

Quotable Takeaways

• Quantify "fast" into a millisecond budget.
• Profile before you optimize. Never guess.
• Hardware loves contiguous memory and predictable branches.
• The fastest code is the code you don't execute.
• Cheat aggressively if the player can't tell.
• Prioritize stability and worst-case over average FPS.

Recommended Learning Path:

1. Profiling Tools: Master RenderDoc and your engine's profiler.
2. CPU Microarchitecture: Learn about cache lines, pipelining, and branch prediction.
3. Data-Oriented Design: Study ECS patterns and memory layouts.
4. Rendering Pipeline: Understand the journey from Draw Call to Pixel.
5. Visibility & Culling: Explore Quadtrees, Octrees, and Occlusion.
6. Automated Testing: Learn to write performance regression tests.

For the full visual deep dive, watch the original video here: SimonDev - How to optimize (almost) anything.