[Dev] Performance Improvements Thread

[Quintillus]

I did try running the Mono profiler, but it doesn't generate the output.mpld file for me - maybe it doesn't work on Windows? Or maybe it puts it in an unexpected place, but it's nowhere in the C7 folder. I made some progress on getting a Linux VM set up yesterday, but then got distracted... with C7 settler AI training being one of the distractions.

Hmmm... memory access is a lot slower than cache access, but I suppose it also depends on whether the thing we're regenerating them from is in the cache. It's a fair point, and compatible with my favorite code review comment of, "Do we have measurements that this makes things faster?"

Thanks for explaining more about how modern GPUs work. I think I also just realized by "pull from the same texture", that is why we are using e.g. the entire river tile, and using a section of it, instead of setting up each section as its own texture. That would mean the GPU can draw all of the river directions in a single call, rather than have to use 16 calls due to the 16 sections (and far more if they aren't all grouped in order). It makes sense about the z-buffer as well.

 

[Flintlock]

I did try running the Mono profiler, but it doesn't generate the output.mpld file for me - maybe it doesn't work on Windows?

That could be it. I didn't try running it on Windows, only Linux.

 

[WildWeazel]

Yeah... right now I'm on my laptop, just displaying a 1024x768 terrain-only (no units) map, and Godot uses 3-4% CPU. Which doesn't sound like much, but this is a hex-core CPU with hyperthreading, so that's about 25-33% of a CPU, not really lightweight. I brought my charger, which is a good thing as I'd probably be out of power by now (after about 2 hours) otherwise. Granted it's not the world's largest battery and has 14% wear, but even if I set C7 to run on the iGPU, it's not easy on it. But at least the cooling is robust on this laptop. If the fan's running, it's at low and I can't hear it above the background noise.

It's also using about 30% of my GPU power, a GTX 1050 Mobile, verified to be using the dGPU, not the iGPU, according to Task Manager on Windows 10. This is with vSync enabled on a 60 Hertz monitor, so I don't see why it should be so intensive. Civ3 ran well on my low-end dedicated GPU that was new in 2002, back when I joined CFC, and ran poorly on an upper-midrange GPU from 1998, so using 30% of a low-end GPU from the mid-2010s already seems suspicious. Although this is on the "Rivers" branch I'm working on, without Flintlock's latest performance improvements.

It's perhaps my biggest remaining concern about Godot. I like programming in it, but we shouldn't already be heavier-weight than Civ4, should we? Although I'm also aware that modern game engine != great performance; some of the fan-spinniest titles I have on Steam are indie titles that don't have particularly impressive graphics, and AFAIK aren't pegging a core on AI like Civ3 will do on large maps.

Let's keep an eye on this. Using a game engine will obviously add some overhead, but this should be a very lightweight project. I wonder if we're already doing something wrong/inefficient with the way we're loading and displaying graphics. There are plenty of mature 2D games with a lot more graphics on the screen and I haven't heard of any resource issues with Godot in particular. But then, that usage could mostly be the baseline of Godot itself, and not linear with the amount of stuff on the screen. It's worth seeing if there's a measurable difference between that and a more populated map, and a blank scene, and an exported build.
Some quick searching turned up that physics shouldn't make an appreciable difference if there are no nodes implementing physics calls, but we might as well try PhysicsServer.set_enabled(false) and Physics2DServer.set_enabled(false) since we have no need for any physics engine.