Sorry, but no. If that was the issue, I (and many others) would have exact same lag in 1.5 as well.
Sorry, but I did this precisely on 1.5. The 1.6 patch reduced stuttering further, 1.6.1 did no difference, and lowering RAM speed had lower impact under 1.6.1 (tested it yesterday). I guess the endless firing event was a good part of what I saw, given the firing instructions are in the damn RAM.
Now, I do acknowledge the dayflow is kinda slower on 1.6.x whitch is a sign of a CPU having more to chew, and has nothing to do with stuttering. Lag is a network related word meaning delay between emission and reception so for solo play I don't know what you're talking about?
I never said RAM speed was THE problem or even A problem, just that for RAM access heavy applications it helps. A CPU not waiting its RAM wastes less cycles and computes quicker a given instruction. Now if a CPU has natural waiting times in between RAM accesses and those are separated from view thread, the overal speed won't change but you can get stutter upon access.
When ordering my 15 'vettes to go to the other side of my solar system, their movements are not smooth. And unless I'm the only one, and despite the dayflow doesn't stall, that's the CPU having to change multiple things at the same time in RAM (ship position for everyone, AI thingies, etc). I still lose 20fps for a sec just giving the order.
Isn't that what OP describes?
The frames are all over the place, ranging from 8-60. Much worse is the percived lag tho. The game feels unsmooth from the very first year.
Ok, I grant you he used the word lag.
That alone was worse in 1.5. In 1.6 this is dayflow being slow, so overall calculation.
RAM speed won't make a game playable from unplayable, but can help things being smoother a bit. Maybe the lower RAM speed guys have the worst experience so I asked to check it. If the concern is dayflow, you're looking at CPU speed. Going from 3.7Ghz to 4.5Ghz was nice for that, but didn't alter stuttering.
I still could do with code optimization or overall calculation simplification, as the real issue is indeed throwing a s***ton calculation load to CPU without going LN2 to cool it and climb @7.0Ghz. Thus we need more efficient code.
But for those not wanting to wait after the devs and able to do so, a significant OC can bring comfort.
P.S. :
@Rattenmann you are CPU bottlenecked. Everyone is. The remaining 33% will never see a stellaris instruction in it's current state (unless you're single core, but that would be a weird result). Mainly because there's a limit to what one can do without knowing the result of other actions. The cores can't be 10 at changing a light bulb.
A bottleneck isn't always that easy to spot.
