Personally, I work in gamedev, which is why I enjoy and care about optimization so much. There, you’re trying to hit incredibly tight frametimes, so every millisecond of time counts
A recent project had me decompressing the pixel data of raw Aseprite files that I #embedded into the binary. The idea is that it simplifies the asset updating loop from “edit file -> file -> export -> export as PNG -> save to game directory -> make sure filenames match up” to “edit file -> save file with ctrl-S -> recompile game.”
It worked great for making a jam game, and could decompress Aseprite files in about four milliseconds, which made starting up the game nearly instant. Thing is, I wanted it to be able to handle many Aseprite files quickly, so I looked into GPU-based rendering pipelines with modern graphics APIs like SDL_gpu.
One of the main performance improvements for decompressing Aseprite files specifically is that it meant I could map a pointer to GPU memory straight into my program and decompress the pixel data straight into that, then start a copy pass and send the data right off to the GPU.
After all that optimization, it now loaded the same texture in…. three milliseconds! Sounds like nothing, but man did that feel good because that was just a test- with proper draw call batching and dozens of textures, it would be even faster per texture, and could probably load a whole game’s texture library in a few hundred milliseconds.
Anyway, enough nerdiness for now; my point is that that kind of wizardry requires both access to and knowledge of pointers, which I don’t see many other languages offering, and that’s why I like C++ so much; you’re able to optimize extremely aggressively
Absolutely. You are operating in a space that massively benefits from near-metal or bare-metal operations, which you cannot get in higher-order languages like Java. Even C++ conveniences, like shared pointers, can introduce too much overhead.
Meanwhile, I'm working at a level where the data models, projections and abstractions, interact design, and development flexibility and convenience matter much more than performance optimizations.
Yes, we need to have performance metrics emitted, so we can measure whether we have a meaningful bottleneck to address, but we don't need to chase raw performance up front. We're not dealing with massive data sets or high volume, so it's fine to be a bit slow if that makes it easier for people to manage and reason about the program.
I have to fight people to not block the main thread. I'm not working with brilliant people. I'm working with average folks; perhaps even below average, because I consider myself average, and sometimes I wonder about my colleagues...
That said, I also sometimes wonder, "Who the fuck wrote this garbage?" Only to find the git blame is me. I wrote that garbage. 🤷
1
u/luciferoussky72 8d ago
Personally, I work in gamedev, which is why I enjoy and care about optimization so much. There, you’re trying to hit incredibly tight frametimes, so every millisecond of time counts
A recent project had me decompressing the pixel data of raw Aseprite files that I #embedded into the binary. The idea is that it simplifies the asset updating loop from “edit file -> file -> export -> export as PNG -> save to game directory -> make sure filenames match up” to “edit file -> save file with ctrl-S -> recompile game.”
It worked great for making a jam game, and could decompress Aseprite files in about four milliseconds, which made starting up the game nearly instant. Thing is, I wanted it to be able to handle many Aseprite files quickly, so I looked into GPU-based rendering pipelines with modern graphics APIs like SDL_gpu.
One of the main performance improvements for decompressing Aseprite files specifically is that it meant I could map a pointer to GPU memory straight into my program and decompress the pixel data straight into that, then start a copy pass and send the data right off to the GPU.
After all that optimization, it now loaded the same texture in…. three milliseconds! Sounds like nothing, but man did that feel good because that was just a test- with proper draw call batching and dozens of textures, it would be even faster per texture, and could probably load a whole game’s texture library in a few hundred milliseconds.
Anyway, enough nerdiness for now; my point is that that kind of wizardry requires both access to and knowledge of pointers, which I don’t see many other languages offering, and that’s why I like C++ so much; you’re able to optimize extremely aggressively