Ykkrosh Posted March 2, 2011 Report Share Posted March 2, 2011 Based on this replay log, I've tried doing a bit more profiling and optimisation, to see what gains can be had without any changes to behaviour. (It'd be easy to e.g. run the AI scripts less frequently so they take less time, but I'd prefer to make them faster before making them less responsive). Running in simulation replay mode (i.e. no graphics) I get the following average times per turn, over the 15212-turn run (on a 2.16GHz Core 2 on 64-bit Linux):24.8 msec/turn in r8999.22.4 msec/turn in r9000 (improved long-range pathfinder).21.0 msec/turn in r9001 (improved obstruction grid computation).18.2 msec/turn in r9001 plus the SpiderMonkey method-JIT.16.7 msec/turn in r9001 plus the JIT plus various AI-related optimisations (not committed yet).Annoyingly there's no major bottlenecks that can be fixed for massive speedups, there's just a series of things that each give ~10% improvement.The current time seems to be spent very roughly ~20% in CCmpUnitMotion::Move (which does collision-detection for every movement, and also triggers UnitAI and AIProxy scripts by updating unit positions, and does some other stuff too), 10-20% in CCmpRangeManager::ExecuteQuery (finding enemy units in range), 5-10% in CCmpRangeManager::ExecuteActiveQueries (also finding enemy units in range), ~10% in AI scripts (sometimes rising to around 20% for short sustained periods), and a load of things each under 5%. Pathfinding (both long-range and short-range) averages in the <5% region, but has occasional large spikes.Some likely conclusions:* Improving the average performance is hard. Replacing some code with a clever super-efficient zero-time algorithm can never save more than about 10% of the simulation cost - the only way to make significant progress is to make lots of incremental small improvements.* Multithreading certain bits of code (AI scripts, pathfinding) won't really help average performance on multi-core processors - they'll just save 5-10% at best.* On average, in this kind of scenario, things are already fast enough - at the normal rate of 5 turns per second it's using <10% of the CPU for all the simulation code, which is fine.* Simulation performance isn't the most important thing - graphics performance and network latency and out-of-sync checks probably matter more for players.* Average performance isn't important (except for replay mode, and time-warp mode, etc). What makes players unhappy is jerky framerates caused by worst-case performance spikes, so I should probably focus more on that. The pathfinders and AI scripts are responsible for most spikes, and multithreading would help smooth those out over multiple frames. Better pathfinding algorithms would help with the worst spikes. None of that will be totally straightforward to implement, though. Quote Link to comment Share on other sites More sharing options...
feneur Posted March 2, 2011 Report Share Posted March 2, 2011 Sounds good overall I'd say. And added together it's not too bad, my math might be lacking, but as far as I can tell it's 30% faster after those changes, so a few more like this and the game is going to be speedy like a bullet =) (Then there's another feature added and it's slower again, but that's the continual battle ) Quote Link to comment Share on other sites More sharing options...
Pureon Posted March 2, 2011 Report Share Posted March 2, 2011 Philip, I have got to buy you a beer sometime. Fixing the jerky framerates is top of my wishlist, so even seeing the performance improvements from r8999 to r9001 makes me Quote Link to comment Share on other sites More sharing options...
Bitiquinho Posted March 3, 2011 Report Share Posted March 3, 2011 I think that's great performance improvement. And, am I right to think that, since you are at alpha version, the game still has a lot of debug code slowing things down, and, when this are removed, the game will speed up a little more ? Quote Link to comment Share on other sites More sharing options...
Ykkrosh Posted March 3, 2011 Author Report Share Posted March 3, 2011 There isn't any debug code that has a significant effect, except for out-of-sync checking in multiplayer games which takes ~20ms and currently runs every 500ms. Quote Link to comment Share on other sites More sharing options...
liamdawe Posted March 3, 2011 Report Share Posted March 3, 2011 Honestly:* On average, in this kind of scenario, things are already fast enough - at the normal rate of 5 turns per second it's using <10% of the CPU for all the simulation code, which is fine.That on a core 2 which is older now as well and clocked low is pretty dam good. I would say it's optimised enough for now! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.