Three documented engagements where AR/VR applications had measurable performance problems. Each case covers what was found, what changed, and what the hardware recorded after.
A logistics company's AR training tool dropped to 18 fps under normal operating conditions.
The application ran on standalone headsets with limited GPU bandwidth. Profiling revealed 340+ draw calls per frame, most from unbatched environment geometry. Shader complexity on the overlay layer added another 4ms per frame. Both were addressable without touching the content pipeline.
Peak memory usage hit 94% of available VRAM during scene transitions.
The simulation loaded full-resolution assets for all scenes simultaneously, including scenes not yet visible. Texture streaming was absent. Rebuilding the LOD pipeline and introducing async scene preloading reduced peak memory demand and eliminated mid-session crashes on lower-spec headsets.
Motion-to-photon latency measured at 34ms — above the 20ms comfort threshold for most users.
The render pipeline submitted frames synchronously, stalling the compositor. Restructuring submission timing and isolating the UI overlay into a separate render pass removed 21ms from the loop. The fix required no content changes and deployed without disrupting the retail rollout schedule.
The application performed well in lab conditions but degraded sharply after 8 minutes of outdoor use.
Thermal profiling showed the GPU sustained 98% utilization continuously, even during static frames. The application re-rendered every frame identically with no dirty-region logic. Introducing frame caching for static UI elements and reducing shadow map resolution brought sustained GPU load to 61%, eliminating throttle-triggered frame drops.
Every engagement started with hardware profiling before any code changes. Assumptions about bottlenecks were wrong in three of four cases.
None of the cases required a full engine or content rebuild. Targeted changes to render submission, asset loading, or batching resolved the core issue each time.
Solutions that work on PC VR often fail on standalone headsets. Each fix was validated on the exact target hardware, not on development machines.
Observations that held across all four engagements, independent of platform or application type.
In three of four cases, the development team had already identified a suspected cause. Profiling contradicted that assumption each time. Shader complexity, asset loading order, and frame submission timing were the actual culprits — not the code paths under suspicion.
None of these applications shipped broken. Each degraded incrementally as features were added without profiling checkpoints. By the time the problem was visible to users, it had multiple contributing causes layered on top of each other.
Reducing draw calls in the AR training case exposed a secondary bottleneck in the audio thread scheduling. Optimization work rarely ends cleanly — it tends to reveal the next limiting factor. That is not a failure of the process; it is how hardware-constrained systems behave.