Hello and welcome to Stellaris Performance Analysis #1. In the first issue the test philosophy is explained, some reference data is gathered and a simple study is done.
The scope
Performance of Stellaris is quite a popular discussion topic, however, most of these describe performance issues with the "game lags like hell in the endgame" level of precision.
In order to elevate precision level, it is proposed to record the exact time it takes to reach a certain in-game date and then use this number while comparing different cases.
The method
A special data logger is used to capture:
The sampling ratio of data logger is set to 1 kHz.
Additionally, a save watcher runs in parallel and backs up save games in case detailed investigation is required. Finally, the idle mode disabler AutoIt script is activated.
The data logger's and save watcher's impact on PC performance is shown on figure below:
The limitations
To minimize impact on data logger performance, the data is logged in binary form. PowerShell parsers convert binary log into csv one with recalculated amount of milliseconds it took to pass from one day to another. This method allows to exclude the time game was on pause, however, the pause effect on game performance is at the moment unknown.
As such, it is recommended to record games without pauses. Also, games should run on same speed as there is no method yet to reliably convert values from one game speed to another.
Test setup
All games were run on the following PC:
MATLAB is used for plots building. The typical plot is looking like that:
However, given the data density, the plots are quite hard to comprehend. Gaussian smoothing with window of 720 days (guesstimated value) is used to obtain final plot:
This concludes the testing philosophy.
The scope
Performance of Stellaris is quite a popular discussion topic, however, most of these describe performance issues with the "game lags like hell in the endgame" level of precision.
In order to elevate precision level, it is proposed to record the exact time it takes to reach a certain in-game date and then use this number while comparing different cases.
The method
A special data logger is used to capture:
- in-game date change;
- game status (paused/unpaused/speed change) change.
The sampling ratio of data logger is set to 1 kHz.
Additionally, a save watcher runs in parallel and backs up save games in case detailed investigation is required. Finally, the idle mode disabler AutoIt script is activated.
The data logger's and save watcher's impact on PC performance is shown on figure below:
The limitations
To minimize impact on data logger performance, the data is logged in binary form. PowerShell parsers convert binary log into csv one with recalculated amount of milliseconds it took to pass from one day to another. This method allows to exclude the time game was on pause, however, the pause effect on game performance is at the moment unknown.
As such, it is recommended to record games without pauses. Also, games should run on same speed as there is no method yet to reliably convert values from one game speed to another.
Test setup
All games were run on the following PC:
- Core i5-3570K
- 16 GB RAM
- GeForce GTX 1060 6 GB
- Win10
- the PC is restarted before each logging session;
- the game is launched via Plaza launcher and set up:
- desired sliders' positions combination is set;
- desired game speed is set;
- game is manually saved;
- game is left to wait on pause.
- the data logger is launched;
- the save watcher is launched;
- the idle mode disabler script is launched;
- game can be unpaused and played.
MATLAB is used for plots building. The typical plot is looking like that:
However, given the data density, the plots are quite hard to comprehend. Gaussian smoothing with window of 720 days (guesstimated value) is used to obtain final plot:
This concludes the testing philosophy.
Last edited: