In game development there is a lot of C/C++, in business applications C#. I have seen C/C++ devs express concern over how a single line of code translates to assembly. In .NET some go into IL, rarely.

In C#, "micro-optimizing" is frowned upon, rare and usually a waste of time. This does not appear to be the case in game development.

What specifically creates this inconsistency? Do games constantly push the limits of hardware? If yes, as hardware improves should we expect higher level languages to take-over the gaming industry?

I'm not looking for a debate on the feasibility of C# as a game dev lang. I know it's been done to some degree. Focus on Micro-optimization. Specifically, the difference between Game Dev vs Applications dev.

By Game I mean modern, largescale development. E.G. MMORPG's, Xbox, PS3, Wii...

  • 3
    I've worked as a games developer and an application developer and the differences are moot. Micro optimisation without profiling is frowned upon on in both. Many games don't have very powerful requirements and dont require any optimisation. Some business applications require far more stringent requirements (e.g. uptime and real time guarantees) than an average 60Hz game. Dec 30, 2013 at 16:18
  • 1
    One extra factor is that in business applications, you can usually choose the hardware (within reason). If I need more processing power, I can just buy another server, or pay for more time on AWS. In games, requiring the latest hardware turns a $60 game into a $1,060 game and video card. If you're developing for consoles, upgrading hardware might mean delaying for years waiting for the next generation. When you can't get better hardware, you have to make better use of it.
    – Andrew
    Aug 10, 2017 at 16:56
  • 1
    related: wiki.c2.com/?PrematureOptimization
    – Peter
    Dec 13, 2018 at 22:07

11 Answers 11


In Business Applications, CPU is not always the bottleneck. A business application would spend most of the time waiting. E.g.:

  1. waiting for results from database query
  2. waiting for Web request to finish
  3. waiting for user to make an UI action

Thats why code that optimizes processing performance does not add too much value.

Primary consideration is:

  1. Time to market
  2. Simplicity, can someone else understand and maintain the code
  • 6
    I would point out that code that optimizes database queries can greatly improve the usability of business applications.
    – HLGEM
    Mar 31, 2011 at 15:14
  • 4
    +1. Database and Network optimization would usually give more bang for buck in business application. E.g. choice of JSON vs XML and tuning DB indexes Mar 31, 2011 at 15:16
  • 2
    +1 but you should add the other side of the equation : the "main loop(s)" and rendering(s) in games on witch the fluidity of the game rely on makes each microsecond lost a loss of value, because quality is perceptible to the eye and other senses.
    – Klaim
    Mar 31, 2011 at 17:41
  • 1
    Well said. And indeed, having done business apps and game development, I have spent time poring over a complex SQL query trying to eke out some more performance, much the same as I have spent time poring over an inner loop in a game. Mar 31, 2011 at 20:30
  • It all comes back to premature optimization is the root of all evil. Profiling clearly reveals that most of the time spent in your average business application is network + database IO. Dec 14, 2018 at 2:32

In business applications, it's very rare for microseconds to matter. In games, it's a fact of life.

If you want to have a game running at 60 frames per second, you have ~ 16.67 milliseconds to do everything that needs to be done for that frame - input, physics, gameplay logic, audio, networking, AI, rendering, and so on; if you're lucky, you'll run at 30 fps and have a luxurious 33.3 milliseconds. If a frame takes too long, your reviews will suffer, your players will fill internet forums with bile and you won't sell as much as you might (not to mention the blow to your professional pride) and if you're really unlucky you will find your team coding business applications for a living.

Of course, game developers don't worry about every single line as, with experience and a decent profiler, you learn which lines need worrying about. On the other hand, those worries will sometimes touch things that in the business world would probably be considered nano-optimizations rather than micro-optimizations.

Dont't expect any high-level language to kick C++ out the door until one offers comparable, and predictable, performance.

  • 8
    In high-frequency trading applications, microseconds matter a lot!
    – quant_dev
    May 11, 2011 at 21:36
  • 2
    @quant: As with most stream-processing applications - robotics, power grids, rocketry, medical technology, etc. Build up too much of a backlog and it may be too late by the time you catch up.
    – Aaronaught
    May 11, 2011 at 22:39
  • @quant_dev: High-frequency trading applications are very rare.
    – molbdnilo
    May 12, 2011 at 6:01
  • Not any more. They're rarer than accounting applications, but more common than, say, airplane design software.
    – quant_dev
    May 12, 2011 at 7:17
  • Microseconds matter in business apps too, the bottleneck is just usually found elsewhere (across the network, in a database or file system).
    – RubberDuck
    Jan 2, 2016 at 16:48

Okay, so you've seen C and C++ developers obsessing over individual lines. I'd bet they don't obsess over each and every line.

There are cases where you want the maximum performance, and this includes a lot of games. Games have always tried to push the performance limits, in order to look better than their competition on the same hardware. This means that you apply all the usual optimization techniques. Start with algorithms and data structures, and move in from there. By using a profiler, it's possible to find where the most time is being taken, and where it's possible to get significant gains from micro-optimizing a few lines.

This isn't because the languages force people into that, it's that people choose languages based on what they want to do. If you want to wring the last bit of performance out of a program, you won't write C# and compile to the CLR and hope the JIT compiler (or whatever) does a good job, you write it in something where you can largely control the output. You'll use C or C++ (and probably a restricted subset of C++) and study the assembly-language output and profiler results.

There are plenty of people who use C and C++ and don't worry too much about the details of translation, as long as it seems to be fast enough.


Do games constantly push the limits of hardware?

Yes, they do.

If yes, as hardware improves should we expect higher level languages to take-over the gaming industry?

Not really - because as hardware improves, consumers expect games to improve too. They don't expect to see the same quality of game developed more efficiently because the developers used a higher-level language. They expect to have their socks blown off by every new platform.

Of course, there is some movement. When I was a lad and first interested in game development, it was handwritten assembly, or get the hell out. This was the Commodore 64 era. Nowadays, of course, C++ is the lingua franca of most game development. And indeed, we've even seen movement towards using C++ for engine code and a higher-level scripting language for game logic code. e.g. LUA, or the Unreal engine has its own UnrealScript language.

  • 1
    +1 a good portion of game devs these days use a hyper-optimized engine layer written by someone else, then use something like Python, or less meticulous C++ to wrap things together. May 11, 2011 at 21:44
  • Relevant to note that Unreal has now moved its scripting “backwards”, from UnrealScript to C++. It's a great thing about modern C++ that it allows you to write both micro-optimised low-latency code, and concise high-level logic. Most other languages only achieve high-level by sacrificing latency and often also performance. Mar 6, 2016 at 14:47

In C#, "micro-optimizing" is frowned upon, rare and usually a waste of time. This does not appear to be the case in game development.

If you can just assemble your application with high-level code and library code, sure it's a waste of time. Write it in an interpreted language if you want in that case; won't make much difference. If you are trying to implement cutting-edge global illumination engine which voxelizes dynamic scene content on the fly in real-time like CryEngine 3 did, you naturally can't get away from the need to micro-optimize.


"Game" is quite an encompassing term. If you had, say, an MMORPG, smaller optimisations would effect many players.

Gamers are, and have probably always been, used to a comparatively large amount of things happening at once, in realtime. Sure; at one time, having a responsive Pacman or Tetris was the goal. But they still had to be responsive. Nowaydays, 3DMMORPGs over packet-dropping network-connections.

I sure understand the want to optimise.


Games constantly do massive amounts of background processing. Business apps don't.

  • 4
    Don't do a lot of business apps, do you? May 12, 2011 at 0:33
  • 2
    Enough to know that business apps don't need to update their status 60 times per second. Furthermore, I specifically said "constantly."
    – user16764
    May 12, 2011 at 5:17
  • 2
    Ever heard of real-time trading? May 12, 2011 at 5:26

I always found the term, "micro-optimization", rather ambiguous. If some instruction-level changes to memory layout and access patterns makes something 80 times faster from a disciplined professional measuring their hotspots with no reduction to algorithmic complexity, is that a "micro-optimization"? To me that's a "mega-optimization" to make something 80 times faster on a real-world use case. People tend to talk about these things like such optimizations have microscopic effects.

I'm not working in gamedev anymore but I work in VFX in areas like path tracing, and I've seen many implementations of BVHs and K-D trees out there which process ~0.5 million rays per second on a complex scene (and this is with multithreaded evaluation). Roughly speaking I tend to see a straightforward implementation of a BVH in a raytracing context at under 1 million rays/sec even with multithreaded evaluation. Except Embree has a BVH that can process over 100 million rays on the same scene with same hardware.

That's entirely due to "micro-optimizations" that Embree is 200 times faster (same algorithm and data structure), but of course the reason it's so much faster is because the developers at Intel behind it are professionals who lean on their profilers and measurements and really tuned the areas that mattered. They weren't changing code willy-nilly out of hunches and committing changes which made 0.000000001% improvements at the cost of significantly degrading maintainability. These were very precise optimizations applied in judicious hands -- they might have been microscopic in terms of focus but macroscopic in terms of effect.

Naturally with the real-time frame rate requirements of games, depending on how high-level or low-level you're working in with the game engine (even games made with UE 4 are often implemented at least partially in high-level script, but not, say, the most critical parts of the physics engine), micro-optimizations become a practical requirement in certain areas.

Another very basic area that surrounds us daily is image processing, like blurring high-res images in real-time and maybe doing other effects on them as part of a transition which we've probably all seen somewhere, perhaps even an OS effect. You can't necessarily implement such image operations from scratch looping through all the pixels of an image and expect such real-time results at matching frame rates. If it's CPU we're usually looking at SIMD and some micro-tuning, or we're looking at GPU shaders which tends to require a micro-level sort of mindset to write effectively.

If yes, as hardware improves should we expect higher level languages to take-over the gaming industry?

I rather doubt the hardware advancements alone could do that, because as the hardware advances, so too does the instructions and the technology (ex: physics on GPU), and techniques, and customer expectations for what they want to see, and competition, in ways that often have developers going low-level again, as with even the case of web developers now writing low-level GLSL shaders in WebGL (web development of this particular sort is arguably even lower-level than it was a decade or two ago, as GLSL is an extremely low-level C-like language, and I never would have guessed a decade or two ago that some web developers would embrace writing such low-level GPU shaders).

If there's going to be a way for performance-critical areas to move to higher-level languages, it's going to have to come more from the software and compilers and tools we have available as I see it. The problem to me in any foreseeable future isn't hardware not being powerful enough. It has more to do with how we can't find ways to most effectively talk to it every time it changes and advances without working our way back to its own language again. It is actually the rapid pace at which the hardware changes that makes high-level programming rather elusive for these areas as I see it, since if hypothetically our hardware stopped advancing out of the blue for the following decades, we might all gradually move to programming all of our games in the highest level languages using Unreal Engine 4 instead of constantly making new engines and kind of resetting that process every time the hardware advances.

Funnily these days, when I'm working in genuine performance-critical areas, I have to somewhat think more low-level than I started (even though I started in Borland Turbo C DOS era). Because back then the CPU cache was almost non-existent. It was mostly just DRAM and registers, which meant I could focus more on algorithmic complexity and write linked structures like trees in a very straightforward way without taking much hit to performance. These days the low-level details of the CPU cache dominates my thinking almost as much as the algorithm itself. And likewise we have multi-core machines which has to make us think about multithreading and atomics and mutexes and thread safety and concurrent data structures and so forth, which I'd say is, in many respects, a much lower-level focus (as in, not so humanly intuitive) than when I started.

Oddly that seems very true to me now. I think I'm more impacted by the underlying and low-level complexities and details of the hardware today than I was 30 years ago, trying my best to take off the nostalgia glasses. Of course we might have talked a little bit of assembly here and had to deal with some gory details like XMS/EMS. But for the most part I'd say there was less complexity and hardware and compiler awareness I required back then than I do today when I'm working in performance-critical areas. And that almost seems true of the entire industry if we put aside like writing if/else statements in a slightly more humanly readable way and consider how much people in general these days are thinking more about the lower-level details of hardware (from multiple cores to GPUs to SIMD to CPU cache and the internal details of how their compilers/interpreters/libraries work and so forth).

High Level != Less Efficient

Coming back to this question:

If yes, as hardware improves should we expect higher level languages to take-over the gaming industry?

To me it's not about hardware. It's about optimizers and tools. When I started people practically wrote all console games in assembly, and there was a genuine performance advantage then especially given the lack of quality compilers generating 6502.

As optimizing C compilers got smarter in their optimizations, then they started to reach a point where the higher-level code written in C was rivaling and occasionally even outperforming the code written by the finest assembly experts in many areas (though not always), and that made it so it was then a no-brainer to adopt C for at least the bulk of the coding for a game. And a similar shift gradually happened at some point with C++. The C++ adoption was slower since I think the productivity boost of going from assembly to C could probably reach unanimous agreement from gamedevs writing non-trivial games entirely in ASM as opposed to going from C to C++.

But these shifts didn't come from hardware becoming more powerful so much as the optimizers for these languages rendering going lower-level largely (although not always entirely, there are some obscure cases) obsolete.

If you can imagine a hypothetical scenario where we could write code in the highest-level code imaginable, with no concern about multithreading or GPUs or cache misses or anything like that (maybe not even specific data structures), and the optimizer was like artificial intelligence smart and could figure out the most efficient memory layouts rearranging and compacting our data, figure out it could use some GPU here and there, parallelize some code here and there, use some SIMD, maybe profile itself and keep further optimizing its IR as us humans do responding to profiler hotspots, and it did that in a way that beats the world's finest experts, then it'd be a no-brainer for even those working in the most performance-critical fields to adopt it... and that's an advancement coming from ridiculously smart optimizers, not faster hardware.


In C#, "micro-optimizing" is frowned upon, rare and usually a waste of time. This does not appear to be the case in game development.

You have a problem of terminology here. You're using the words correctly, but game developers and business people are using the same term in two very different ways.

For business, "micro optimization" means speeding up a very small step in the overall business process implemented by the software. The reason it is frowned upon is typically one of:

  1. Extra money spent delivering the same business value, at a few seconds faster speed. The money saved in the speed improvements come from a different pool of money (the user's time) so the business doesn't generally benefit from the effort it expends, the client does at the expense of the business.
  2. Typically business programmers have bad visibility in the overall business process, so an optimization of a single step might not yield good benefits to the overall process. For example, if you make 3% of the process 10x faster, you have sped up the entire process 2.7%.
  3. Typically business has a large list of remaining work that has some business value, and would prioritize adding that value instead of delivering the same value in a (probably) smaller time.

Game development is a different beast. "micro optimization" is saving a small amount of time in a function or routine.

  1. Gaming systems tend to be held to the rendering cycle. Currently the golden standard is 60 frames per second, so everything that is going to be calculated needs to be done and rendered to the screen in 1/60th of a second.
  2. This means that often the same routines are called thousands to hundreds of thousands of times over the course of a game. Thus a 10x improvement in a single function is magnified in value by the number of times the improvement's benefits will be felt.
  3. The failure to achieve the rendering rate has an impact on the presentation of the game. Video will become choppy, characters will animate with skips and jumps instead of fluid movement. This immediately brings the player out of the game's immersion, and into the realm of questioning the game's value.

So in business, nobody cares if the form of a 4 step business process presents in 0.6 seconds or 0.5 seconds. While in gaming, one cares if a routine that takes 200ms can be reduced to execution in 100ms.

It's all about the value delivered to the client, the client's needs, and the cost-benefit ratio of the change.


It has to do with why that tool was selected for a particular job.

Golfers will obsess over the direction and force they apply with a putter, not so much when they're using the driver.

Why? Because they're different kind of shots. For a drive, you want to get it in the fairway with maximum distance. For a putt, you want to get it exactly in the hole.

Same applies here. Game developers choose C++ because it gives them control over the performance of different operations. If you've chosen that, you're going to want to leverage it.


Most business applications are written as in-house tools. Expectations about the usability of this tools are much lower than in the case of software sold to mass customers. It is quite common that an in-house business app has menus and dialogs which react slowly to mouse clicks, windows which redraw with delay, or even a GUI written in Swing (the horror!). This due to a number of reasons (it is more important that the software is customizable than that it is very "snappy", the users of the software have no choice whether to use or not use the software in question, the people who make the decision to install the software do not use it themselves...). The consequence of all this is that the developers of this tools do not spend much time optimizing the responsiveness of the application, but care a lot about the extensibility and number of features. Different client base => different design goals => different methodology.

Note that a business application targeting a mass audience, such as Excel, IS heavily optimized.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.