Frame timing spikes

[volca02]

I need a better tool to track down the frame timing issues (to be easily seen in t1/miss2.mis starting position for example). Something tells me it is some kind of a lazy initialization, probably avalanches of object placement/lighting calculations etc. A tool that shows that exactly is needed.

[volca02]

I think we can introduce a tracer macro spawning a RAII object that will inform some object about the current running/terminating tasks. Then we can stick it throughout the code and build a tool to review the results.

The macro would be opt-in via a cmake flag (otherwise compiling to nothing).

The RAII would call start(func) in ctor, stop(func) in dtor. The resulting data would get written in a vector (microsecond time, function name) and could be analyzed.

[volca02]

A few remarks:

• should really focus on dynamic memory allocation in the visibility determination code. This is one of the problem sources
• consider jemalloc or other allocator in general to somehow mitigate the problem

[volca02]

Frame spikes are caused by lights. What happens is that light list population gets too pessimistic, light lists get enormous. And current ogre3d does not help at all, thanks notably to these two commits: b02a054fff, cf09575fb2 which devirtualize key methods that could be used to handle the light population better. It could probably be solvable with movable listener but it seems more and more like stapling tentacles to a horse to make it look like an octopus.

What will follow is departure from ogre3d, it does not serve the needs of the project too well.