jK wrote:QTPFS update
Some things I noticed:
1. QTPFS causes cpu spikes at the beginning (it locks cpu >100ms), may be it is possible to share work across multiple gameframes somehow? e.g. calculating the path iterations could happen in stages?
2. is it possible that stucked units cause massive cpu load?
3. if 2nd issue is not true, later the spikes accumulate to a constant lag so the total cpu usage needs to be decreased too
1. I considered that, but it's hard to do because each search would need its own context (plus memory) and terrain deformations could invalidate any partial results. In any case the searches themselves are not so expensive, but the extra work being done during each search (updating neighbor references for every explored node) was, which should now be fixed by d51db40a9f0. Might need a new oprofile run though.
2. Unlikely, but units trying to find a path *to* unreachable nodes could cause spikes and AI's often spam such orders.
I recompiled with RELEASE and noticed it runs MUCH smoother there (note, I cannot create profile graphs with such a build). Seems something in DEBUG2 & PROFILE multiplies the load (some massive recursive functions?). Still QTPFS makes 50% of SimLoad, esp. the spikes are still there. So (1) & (2) are still valid.
QTPFS has its own special debugging #definitions (DEBUG(2) only enables some trivial asserts), so I assume the code is just very cache-inefficient without compiler optimizations.