Spring RTS Engine

Hi,

On my PC then I am first AI this method takes 13 seconds in AA mod. Then I looked at sources of UnitHandler and SunParser I see a lot inherently slow code. But I didn't try to prove it, as I didn't try to compile Spring myself (for development of AI using VS2005 and release version of Spring).
Can be done anything with this? Because I generaly need to call it everytime my AI start. Don't want to cache it myself, and IMHO in worst case it should be cached by Spring.

on a normal game without a ai ( or without a ai calling that method), unitdefs are cached as they are need by the engine only, and thats why it takes so long cuz when the game starts very few unitdefs are already cached.

If you know some code that could be cleaned up, just fix it and mail/post the changes. Would be great if you contributed :)

One thing you can do is dump all the unit def stuff to a big file called NameOfMod.dat and then load it back next time your AI starts up.

Of course, all the string data and pointers will be horribly corrupted unless you know how to do it right (which I don't). Even so, if you don't need those data, you can still load it back just fine.

Another option, if you don't need it all right away, is to fill the array one Unitdef at a time, over the course of a few hundred frames.

For myself, I just load it up at the beginning and don't worry about the time it takes.

I will try to speed it up. As soon as I will compile Spring with VS2005

i dont worry about it either, who cares about 20sec on a 30min game ? ..
and about that optimization watchout cuz caching it that way in a file would still not be as good as it seems cuz ull have a lot a mods(there will be quite some times a 1st time and therefore requiring the standart getunideflist()) and reading a couple a hundreds unit info from a file is not fast(its basicly what the engine does when u make that func call, it reads all fbi's files from all units there were unloaded).

Caching it is not modder friendly at all, and there's no way to save pointers like that and re-instate them withouth using code that is similair or the same to what the callback currently is.

A rewrite of the itnerface function is the only valid option

i think that instead of that, there should be a sort of a internal check up that would see if a ai is present and if so automaticly load all the unitdef table and include that loading time in the normal game load time.
sounds easy and ok to me

VTune show me that during that call 50% time is spend in "fmod" function. I will investigate more from there this come or if it is even true.

If you are doing your tests on the 0.67b3 source, you should know that SunParser has been completely rewritten in the current portable source tree. UnitHandler is still pretty much the same I think though.

I just did some mesuaring: (sources from SVN)
Original time: 15s
Then I commented out loading of BuildPic: 5s
Then I commented out loading of sounds: 3s

So best way to speed it up is be more lazy with loading of BuildPic.
Then probably change these 2 std::vectors into one std::map in Sound.cpp
Then in TdfParser::SGetValueDef is superfluos lowering of string done again in SGetValue.
And generaly TdfParser could be improved, like not create error messages then nobody wants them ...

I will try to create some patch for these. But it will take some time because I like to play Spring