I have noticed this myself, so i tried to get a little test going, since i had two similar saves, one in RoM/AND (1.70 Beta3) and the other in vanilla RoM.
Here's what i found:
Vanilla RoM Save:
Large Earth2 Map, Epic Speed, ~18 civs present
Industrial Era, 36 cities (my own, about 127 world wide)
Time between turns:
Varies from 20-40s
RoM + AND 1.70Beta3 Save:
Large Pw2 Map, Epic Speed, ~18 civs present
Industrial Era, 29 cities (my own, about 100 world wide)
Time between turns:
Varies from 1m:20s-2m
Reading this post actually got me to go back to vanilla RoM to check out the speed and i was surprised to see it go faster, it could be a fluke instance since i dont exactly have a lot of games to do head to head tests on atm, but that's what i got so far.
I can provide both saves if needed.
My findings from the first 10-20 turns is that RoM takes 4-10 seconds, while AND takes 5-10 times that, 30-60 seconds.
(very inaccurate measurements, but that shouldn't matter, as the difference is too great)
Same exact map/starting location/actions.
This is with a standard AND instalment.
I'll try to go through different AND game options next to see if I can identify any culprit.
After reading both your posts, I decided to test things for myself. I ran some test games using exactly the same map (I generated it, saved it as a worldbuilder save, and re-used it).
Here are the results
Rise of Mankind 2.9(w/o A New Dawn) 100 turns: 2:06
Rise of Mankind 2.9(w/o A New Dawn) 200 turns: 6:32
A New Dawn 1.70beta3 (Recommended Settings) 100 turns: 2:32
A New Dawn 1.70beta3 (Recommended Settings) 200 turns: 7:46
A New Dawn was running about 10% slower. So I went and started profiling turn times (with special DLLs, you can turn on engine profiling, which will identify the length the longer functions and code takes to compute). I found that one of the key time consumers was CvPlayer::canTrain(). What that function does is check if units can be built for each player based on civics, the unit limits, techs, and other player-wide criteria. It doesn't take a ton of time to compute, but was being used over 1000 times a turn, in the early game (Late game, it's used > 10,000 times a turn...
). I cached the values. (I made the game calculate once per turn for each unit, saved the results in memory, and the game checks the memory instead of recalculating each time. Much Faster.)
I ran profile tests again on the same scenario as before,
A New Dawn Beta4 (Recommended Settings) 100 turns: 2:10
A New Dawn Beta4 (Recommended Settings) 200 turns: 6:10
So, while it didn't speed up the early game a ton (only a few seconds difference, within error margins, so effectively, the same times), the late game was slightly faster than RoM, and significantly faster than the previous A New Dawn.
I've been doing this a lot lately, Identifying places where the game should cache values in memory instead of recalculating them. Generally, this doesn't speed up the early game any, since the early game hardly uses these values at all, but by the late game, there should be a considerable difference in turn times. Rise of Mankind will slow down immensely in the late game due due to it's use of python callbacks.
One last note here, some irony:
The reason why Rise of Mankind 2.9 feels so much faster than 2.81 is that I submitted a lot of code to improve game-speed to the RevDCM team, and that code got included in Rise of Mankind 2.9. (RoM 2.9 is ~15% faster than 2.8 because of it). I'm competing against myself.
There was couple changes that I made in RoM 2.9 that also increased turn speed: the storm system was "cut down" ie. maps don't usually spawn them at the game start (only random events) and the number of starting players was decreased on giant/gigantic map sizes.
