#game devlopment

Yeah what that says.

I finished the templates but to continue I need to make a few assets. So I restarted work on the first bg (which is the one of the potential 2 I need to release the demo(the second one only appears for a few seconds at the end so in order to release in early/mid october i might just scrap it))

Performance and optimisation, Part One.

Casey Muratori has recently released a terminal application for Microsoft Windows, because the terminal that comes with Windows now is rendering text too slow. If you build a complex application with tens of thousands of source files (if you also compile all dependencies at least), the speed at which the terminal can display compiler invocations becomes a significant bottleneck. Now that processors and NVMe hard disks are so fast, this might even be the most important bottleneck! After Microsoft software engineers in charge of the terminal application publicly declared that it is not realistic, economical, or humanly possible to build a feature-rich terminal application for Windows that runs any faster, Muratori wrote a terminal for Windows that runs orders of magnitude faster, to prove them wrong.

Later he did a stream (VODs are uploaded on YouTube) in which he explained why refterm is so fast, and talked about his philosophy of optimisation.

Refterm is fast because it has an asynchronous design, with one half ingesting and parsing printed lines as fast as possible, writing incoming data to a magic ring buffer, while the UI is running at its own pace in another thread. If data is coming in faster than it can be rendered, it won’t be rendered. Rendering is done on the GPU of course.

There are two ideas from this philosophy I want to highlight:

1. Don’t write slow code! If you don’t have the time and money to optimise, at least, in his words “don’t pessimise” your code. If you catch yourself doing something really inefficient, or if you think the code architecture is forcing you to create a slow implementation, because a fast implementation based on this design is impossible, or bottlenecks that will make the implementation slow are prescribed by the architecture, speak up before it is too late!

2. If you want to optimise it, your guideline should be the maximum theoretical throughput allowed by your hardware. You should calculate how much your system can theoretically handle. Optimised means close to the theoretical optimum.

I think the first is just preaching to the choir, and the second is not practical. If you are talking to an audience of working software engineers who work in tooling, game engines, and operating systems, it’s good to remind them every now and then that their code optimisations will compound and possibly save time for millions of users. If your audience is students, beginners, advanced learners, intermediate learners, or even clueless junior software engineers, it’s useless. If they don’t already know what fast code looks like, something like “don’t write slow code“ is unlikely to help.

The second idea, to strive for the theoretical optimum, feels equally unrealistic. You usually have performance goals, RAM usage goals, a number of users you want to serve, or a certain time you want the phone battery to last. These goals are usually fa from the theoretical optimum. It may help to calculate the most your hardware can give you, or the minimum amount of space you need to store your application state, but most of the time this serves as a sanity check, or prove the theoretical feasibility of optimisation.

In my own experience, the way to optimise your program is:

1. Choose the right architecture, good data structures, and fast algorithms! Big-O notation matters. If your API sucks, the fastest implementation will still suck. If your data structures are slow, even fast algorithms won’t save you if you pass your data structure everywhere and your algorithms everywhere will have to wrangle your poor data structures. If your algorithms have bad asymptotic complexity, sooner or later all assembly wizardry, hardware acceleration, and operating system features will succumb to the maths.

2. Benchmark your application! See if it matches your performance goals. What kind of resources (RAM, CPU, GPU, HDD I/O, network bandwidth) does it utilise? Is it using up all the bandwidth, or does it wait because of poor latency? Does it use unexpected resources? Different types of applications need different types of performance and optimisation for different metrics. You have to measure the right metrics, like frame rate/timings for a game, worst-case response time for a web app, or RAM usage for a chat client.

3. Profile your application! Find where the resource you want to optimise is spent. If most of the time is spent waiting for vsync, good for you! If most of the time is spend in collision detection, maybe invest in better spatial data structures. In all likelihood, Big-O still dominates, and you can gain the most not by re-writing in C or using multiple CPU cores, but by using the right algorithms and data structures. If profiling finds a performance bottleneck in an unexpected part of the program, chances are you haven’t even thought the data structures there and just used arrays.

After I wrote my own post on PyGame’s performance, developer DaFluffyPotato made a video pointing out the importance of using the right data structures to make even something like PyGame run at a decent speed.