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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s