So I have started to do some profiling of Wesnoth. Using google performance tools, I've done both heap-profiling and cpu-profiling. Perftools lets me do some fun visualization.
Some preliminary results.
Heap-profile after starting UtBS and letting the ai play for a couple rounds: http://pages.cs.wisc.edu/~hopman/pprof5163.0.ps
I'm not sure about that part of the code, but I believe that a large part of that SDL_CreateRGBSurface is image caching. Whatever it is, it is a large part of Wesnoth's memory footprint.
CPU-profile of two ais playing on The Freelands. (takes usually ~15 turns). http://pages.cs.wisc.edu/~hopman/pprof-locator.pdf
Now, this is run with no accelerated speed and not skipping ai moves, so not surprising a lot of the time is spent in animation stuff. In fact, for the most part, this is a rather boring graph. However, one thing did really pop out at me, nearly 10% of the time was spent in image::locator::locator(), most of it in image::locator::locator::value::operator<(). Basically, with the amount that that function is being called, string comparisons are way slow.
Now this operator< doesn't really define any important ordering, so I made locator::value store a hash of its fields and check that first for operator<. Here are some results: http://pages.cs.wisc.edu/~hopman/pprof-locator-optimized.pdf
So, about a 5.9% improvement... not too shabby.
Ok, a bit more. CPU from startup (actually just after start) to titlescreen: http://pages.cs.wisc.edu/~hopman/start.prof.ps
and loading campaign UtBS(from like after choosing difficulty to when loading screen changes to next screen) http://pages.cs.wisc.edu/~hopman/campaign_start.prof.ps
Well, I don't see anything too surprising here(I say that as though I know all that's going on in the code...). So, tokenizer::next_token() and things it calls take up a significant part of these (31% and 50%). Not too surprising that it is called a lot. Looking at the code for it, I think there is definitely room for improvement... will need to look into it.