Could I be shipping a debug build by mistake?

Yes, and it's a common cause of 'slow when built.' A development or debug build includes overhead that an optimized release build doesn't, making it slower. Check your export configuration and make sure you're testing and shipping the optimized release build, not a development one, this alone resolves some cases of build-versus-editor slowdown.

How should I measure my game's real performance?

Profile the actual optimized build on representative hardware, including lower-end machines players use, not the editor on your dev machine. Editor performance isn't a reliable indicator of shipped performance because the editor and build run under different settings and conditions. Capturing field performance data from the shipped build on players' hardware shows the performance that actually matters.

Why Does My Game Run Fine in the Editor but Slow When Built?

Q: Why does my game run slower as a build than in the editor?

Usually because of configuration differences: the build may use higher quality settings, a different resolution or vsync, or, commonly, you exported a development/debug build rather than an optimized release build (development builds carry profiling/debug overhead). The editor's lighter viewport or settings flattered the performance; the build is running under heavier or non-optimized conditions.

Quick answer: Your game runs fine in the editor but slow as a build usually because of configuration differences: the build may use higher quality settings, a different resolution or vsync, or, commonly, you exported a debug/development build rather than an optimized release build (development builds carry overhead). Profile the actual build (not the editor) and reconcile its settings.

It's confusing: the game runs smoothly in the editor, but the exported build is slow, shouldn't a standalone build be faster? Usually the difference is configuration, the build and editor are running under different settings or conditions, and the build's happen to be heavier.

Why a Build Can Run Slower Than the Editor

The editor and build can differ in ways that affect performance, not always in the editor's favor. Different quality/graphics settings: the build may default to higher quality (resolution, effects, shadows) than your editor session, so it's doing more work. Different resolution or vsync: a fullscreen build at native resolution with vsync behaves differently than a small editor viewport. Build configuration: if you exported a debug/development build rather than an optimized release build, it can be slower (development builds include profiling/debug overhead). And the build runs fullscreen, standalone, possibly with different settings than the editor you compared.

So 'slow when built' is usually not that the build is inherently slow, but that it's running under heavier settings or a non-optimized configuration than your editor comparison. The editor's lighter viewport or settings flattered the performance.

How to Diagnose and Fix It

Profile the actual build, not the editor, performance must be measured on what players run. Check whether you exported a development/debug build or an optimized release build (a common cause), and compare the build's quality/resolution/vsync settings to the editor's. Bugnet's performance monitoring captures real-world build performance across player hardware, so you see how the shipped build actually performs (the relevant number), not just how the editor felt on your dev machine.

Make sure you're testing and shipping an optimized release build, reconcile settings so the build isn't doing more work than needed (and add scalable options), and optimize the release build on real hardware. See our guide on fixing a game that runs fine in editor but slow when built. The lesson: editor performance isn't a reliable indicator of shipped performance.

A build slower than the editor usually means heavier settings or a debug configuration. Profile the optimized release build on real hardware, the editor's lighter conditions flatter performance.