Back in the day, I spent a fair amount of time working on gutting the DLL because frankly, it was atrocious. My memory is a little fuzzy as it's been +10 years since I've looked at it, but things I remember seeing:

* over use of C/C++ preprocessor macros where an inline function would have been more appropriate to say, get the array/list of CvPlots (tiles) that needed to be iterated over all the time. * lack of hoisting loop invariants out of loops. It is common to see usages of the non-trivial macros above in the bodies of tight loops, often tight nested loops. Optimizing compilers are great, but they're not _that_ great. * the exposure of the C++ types to Python was done...poorly. It was done using Boost Python (which, while a great library for its day had a _huge_ learning curve). For every Cv type in the C++ DLL, there was a corresponding Cy type to expose it to Python. Collection types were _copied_ every call into Python code, which was quite frequent. The collections should have been done as proxies into the underlying C++ collections, instead of as copies.

Most of the changes I made were quite small, but over the course of a month of part-time hacking on it, I'd gotten late game turns down to a couple of minutes from 30-minutes and memory usage was extremely reduced; and I never did get around to fixing the Python wrapper as it would have too intrusive to fix it properly. I could have made more aggressive changes if I had full access to the source, but being constrained by DLL boundaries and C++ types being exported limited what could be done w/o breaking the ABI (had to be extremely careful about not changing object sizes, affecting vtable layout, etc).

Frankly, I doubt the developers spent very much time at all, if any, with a profiler during the course of development with the game.