Comment by simias

7 years ago

It really depends on what you mean by "debug code". If you mean special versions of the code built with "-O0 -g" (or the equivalent in whatever compiler/toolchain they're using) then obviously that's going to be a problem. If it's just helper methods like "go directly to section X in the game", "spawn any monster" or "if global variable DEBUG is 1 then log this" then that can easily make it in the final product if they're not optimized away in production builds. Those won't seriously harm performance either, just bloat the binary a little (which will most likely be totally negligible since modern games routinely end up using dozens of GB).

3 comments

simias

Reply
dijit  7 years ago

I’m sorry, I don’t know what statement you’re making really.

Maybe (uncharitably) you’re trying to look smart or maybe you’re also in the industry and I just don’t understand what you’re saying :/

When I talk about “debug” builds it’s actually a large thing; Not _only_ is it switching the compiler (Microsoft C++ compiler ofc) to build stripped/optimised binaries, it’s also removing things like, built in command consoles, logging subsystems and “phase handlers”, budget profiling for subcomponents of the game (AI, lighting/shadows, props) and also removing all assert statements.

Simple things (like asserts, which are essentially switch statements) need to run in tandem with other processes, when you’re trying to push 60/120 frames per second nearly every switch statement is going to “cost” something. That cost can be high very quickly. So, you don’t tend to leave things in which check conditions of various environment variables.

  • simias  7 years ago

    I'm always trying to look smart but I don't always succeed.

    Anyway, I'm not part of the industry but I do hack around in emulation circles and I've dug pretty deep in some of these old games, my point was that you can definitely end up with dead or almost-dead debug code that doesn't harm performance significantly (because it's never or almost never called) and lingers in the final binary.

    >when you’re trying to push 60/120 frames per second nearly every switch statement is going to “cost” something

    I mean it obviously depends on the frequency of the test. If you have some check every second that reads like:

        if (dump_stats) {
      dump_stats_to_stdout();
    }

    Then it's obviously going to have a negligible impact performance-wise as long as enable_stats is false. Then if this code is not explicitly disabled in the production build you might be able to use a memory hack to switch enable_stats to true and get some potentially interesting output out of it.

    This is not (just) me trying to look smart, it's stuff that you can actually encounter in some games and firmwares in the wild.

  • CameronBanga  7 years ago

    Obviously you know what you’re talking about, but this comment comes off as unnecessarily rude to me. And not befitting of Hacker News.