Optimization potential

The battle in Partôr during week 510 provides an excellent opportunity to do some profiling on Eressea. The whole turn took at least twice as long as usual, and gprof blames a single function for it. I knew this function was bad. The problem is, it really needs to be called this much.

I looked really hard at the usage pattern for the function this morning, and I think I can build a small cache with some information and reuse it for subsequent calls. Anyone dying in the battle invalidates the cache, but still, I figure I might be able to save some 75% of the actual work. Man, I’ve looked at this one at least twice in the past and never seen this!

[Listening to: Battle 22 – Ugress]


Update: It worked. Runtime has gone down from 35:58 minutes to 21:53 minutes. The function is still at the top of the list, but anything more seems to require really big investments in terms of code reorganization. Not something I want to risk. The real problem is the very dynamic definition of distance between two fighters, which is a nightmare to calculate each time and even before the latest trick contained a huge amount of custom hacks to make it faster.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.