Performance Improvements - Development Log #523

In this week's devlog Michi talks about how many small changes increased the performance significantly.

Michi (molp)

While the week before was mainly about identifying performance issues, this week was about fixing them. In the last devlog (#522) I wrote:

The next candidate on the list of potential causes is the way we handle scheduled commands. A command is, simply spoken, an action that the player (or a system of the game) sends to an entity and expects it to do something. An example would be "transfer x units of z from inventory a to b". A scheduled command is an internal command that can be executed right now or in the near future. For example, if we have the segment of a flight, the fleet behavior will schedule a command to end the current flight segment and start the next one, at the time the flight segment ends. The behavior will then get a notification from an internal pacemaker once that time has arrived and can execute that command.

Determining what the next command for an entity is can be costly: we have to go through all behaviors of an entity (ships, contracts, bases, ...) and determine what needs to be updated next. I improved the logging around scheduled commands a lot, and I am sure I will find some performance bottlenecks.

The logging I deployed last week to find the performance bottlenecks revealed that there are two issues:

• There are several behaviors (subcomponents) of the company entities that have rather large execution times
• In some entities the individual behaviors keep below the threshold, but all behaviors added together are taking very long to complete

Since both of these issues are related, I decided to take the time to go through all behaviors of the company entities and to improve the performance of all of them where possible. The idea was that when the individual behaviors get faster and use fewer resources, so does the entity as a whole. Additionally, we can also save some time and resources from a reduced load on the garbage collector.

The worst offenders where the population, workforce and rating behavior, so I started with them first. I implemented a mix of caching strategies for all three. Let's look at the rating behavior because it is the easiest to understand. The rating behavior is simple: it keeps track of the current rating and when it is time to check for the next command, it re-calculates the rating and compares it to the current one. If there is a difference, it schedules a command to update the rating. The calculation of the rating is complex, it considers all relevant contracts, the valuations of these contracts' conditions and finally crunches the numbers to return the rating. Doing this everytime we need the next command is a waste of resources, as the rating rarely changes. Instead, I introduced a flag that marks the rating as dirty, requiring recalculation. There are only a handful of events that will mark a rating as dirty, mostly contract-related. This simple change reduced the load induced by the rating behavior to a fraction, which is a positive. The downside, of course, is that we now have to be extra careful when adding or changing things that should trigger a rating update, as it won't happen automatically anymore.

You might wonder why we didn't implement such a flag from the get-go, and the answer is, because we didn't need to. In the early universe, with way fewer players, it wasn't really a problem to burn a few extra CPU cycles. Our main concern always was memory, but now with additional players and an older, larger universe, the CPU resources became just as important.

While being at it, I also improved the loading times for chat channels and the COM list. They should load quite a bit faster now.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!