Optimization

There’s a technique from the early days of game programming that I keep coming back to. It sounds wrong the first time you hear it. The idea is that the fastest way to draw a sprite isn’t to read its pixels and copy them to the screen. It’s to compile the sprite into machine code and then run it. The sprite doesn’t get drawn. The sprite does the drawing. That’s compiled sprites. And understanding why they worked requires understanding exactly what makes regular sprite drawing slow. ...

Years ago I was working at an embedded software company, profiling a 2D graphics renderer running on an ARM processor. We were trying to squeeze more frames per second out of a UI that frankly didn’t look that complex: a few icons, some solid-color panels, the occasional gradient. Nothing that should have been slow. The profiler told a different story. The renderer was spending most of its time not computing. Just reading. Fetching pixels out of external DRAM, one scanline at a time, pushing them through compositing, writing them back. The CPU sat there waiting. We weren’t compute-bound. We were memory-bound. Almost every optimization instinct I had from years of server-side work was pointing me in the wrong direction. ...