I’ve been working on some QoL features for Revolution. (I’ll do another post about those soon) and I’ve been resisting the temptation to make non-feature-style changes, that is, if I see some existing code scroll past that I’m not working on but I can see could be made better or cleaner, I have had to tell myself to just look at it later. Trying to test changes to new stuff while at the same time editing older stuff (that it depends on) is a recipe for software-engineering havoc.

Well, now is time for all those things I’ve walked past!

Some quick tests before optimization shows we can render the control_screen update() function very fast in a tight loop and we can time how many we can do in 5 seconds:

• 823
• 824
• 830
• 811
• 740

Fairly stable. Mean of 805

Lets see what sort of difference we get with a busier map.

I’ve kept this map for a while, I used it to experiment with a faster way of finding nearby units. The screenshot above shows some old early debug code drawing a red box around the units that it was finding nearby the manta in the middle.

As you can see, there are a LOT of units here for the lua to think about, so its a fairer test of the lua in a busy game. Anyway, we get:

• 356
• 341
• 310
• 306
• 307

A mean of 324 FPS.

Earlier to day I found some dusty old PDF talking about how that lua tables are optimized if they are used _like_ arrays (indexed by sequential integers starting at 1)

I also found some evidence that table.insert(tab, value) is something like 100% slower than tab[1 + #tab] = value

A quick look for table.insert in our lua and we have:

78 things, now, not all of these are in critical places, but some if them definitely are!

So.. I’ll experimentally replace some of these with direct table access using integer indexes and see how much difference it makes

Ok!

Map	1.6.5	Optimized
Perftest	800 fps	874 fps
Busy	330	330

So… basically no difference when it matters!!!lua

Oh well, sometimes that is what happens when you try to optimize code!

That makes sense, testing table.insert vs table[#table] with 10 million items the latter is 20% faster. In CC2 we aren’t dealing with adding 10 million things to a table, we’re dealing with lots of multi-dimensional iteration instead.