Well, I've done some measurements, basicly I ran oprofile for 20 seconds on a small map and for 20 seconds on a large map and I looked at the differences between both.
A first measurement I did was compare the framerate, the small map renders at 140 FPS, the large map at 23 FPS.
(Logfiles can be seen in trac http://parpg-trac.cvsdude.com/parpg/attachment/ticket/197/bench_pre.txt and
http://parpg-trac.cvsdude.com/parpg/attachment/ticket/197/bench_post.txt ).
When I look at the fat functions in the output I note the following:
* 11% CPU: FIFE:Camera::render()
* 9.8% CPU: FIFE::Instance::update()
* 5% CPU: FIFE::Visual2DGfx::isVisible() (inline function used only in FIFE::Camera::render() and only used to conclude that everything is visible ?)
* 4.2% CPU: FIFE::LogManager::instance() (the logging, this one can be easily disabled through use of a macro, but this get called once or twice per instance in FIFE::Camera::render() (starting to see a pattern ? )
* 3% CPU: FIFE::Instance::getVisual() (well, called in Camera::render() for well each visual ...).
Now I added some prints within FIFE:Camera::render() and basicly it iterates over all layers, there iterates over all instances, and collects the objects to render (takes care of animations etc etc) and then sorts the list of instances to render and renders them. But these counters counted the amount of objects per layer etc.
But the conclusion was that one layer contained 62500 instances, the other contained 697 instances, which means for each frame it iterates over 65000 elements, decides whether or not they should be rendered or require some form of updates. (in the ends it decides to render about 700 objects (the number of floor tiles is almost constant, the number of things on the other layer might differ). (It also means that at a framerate of 25 FPS, the logmanager will be asked 25*65000 = 1.625 million times whether to log 'action' or 'no action').
Another example is given a 2GHz PC, say it can execute 2.000.000.000 instructions a second, then this would mean that each instance only has 2.000.000.000/(65000*25)=1230 instructions availabe. Which really isn't that much since this loop isn't the only part in the game .... it will stil require rendering etc etc.
So my initial conclusion would be:
a) we added way too much instances on one map (there is an early opt out thing for invisible instances, but everything with us is invisible)
b) the FIFE::Camera::render() loop isn't optimal.
Some wild ideas popping to my head:
-> the datastructures used in the render might be more efficient, instead of a vector, instances might be sorted in an efficient way, that the loop can be interrupted (so that only 'likely to require work' things are checked
-> remove the logmanager calls from all critical paths (will probably be compiled out i assume in production, at least I hope
they already used macro's for it, but a regular scons build still uses them)
-> the big pain will be the amount of floor times, perhaps we should envisage a methode to make them en-masse invisible/visible, are there mechanisms for this already ?
...
I'd would really appreciate it if somebody could do some double checking and confirm what I just said here (or tell me a liar if i'm telling lies ;-) ).
But at this point my conclusion w
