Performance?

[_Galllex_]

I changed 11900K to 9800x3d. I had 15 FPS and now 23 FPS in the middle of the colony (700 cycle with 3x speed) - CPU load is only 4%.
Is there any real way to optimize and get at least 60 fps?

New DLCs do not bring any optimization. Are the developers planning to move in this direction? Maybe throw them some ideas like simplifying calculations, optimizing movement, not mapping the path for animals, but making them dynamic, multithreading, etc.
P.S. Can all Google servers give 144 fps?

[SGT_Imalas]

On 3/2/2025 at 1:43 PM, _Galllex_ said:

CPU load is only 4%.

not how stuff works

oni runs primarily single threaded, all those extra cores just sit there idle and decrease the total cpu load value.

still, 23 fps at cycle 700 on the best gaming cpu currently existing suggests you have some severe performance hogs in that colony, I had 60fps stable at cycle 2000 on a 5800X3D at x3 speed, the 9800X3D should have much more performance than that.
 

steps you can do to increase performance:
- install FastTrack
- remove any atmo Jet suits
- seal off large areas with a single row of tiles and vacuum out the center (dont fill the area with tiles, thats worse than vacuum and will murder your loading/saving times; if you add doors, make them locked, door permissions alone are insufficient)
- consolidate debris into a single tile to minimize the amount of debris items (pathfinding is the biggest contender for eating performance)
- remove ladders to areas where you dont need them (pathfinding ^^)
- remove multi paths to areas (more than 1 way for a dupe to reach a certain tile; eg. with tons of ladders)
- reduce critter count
- confine critters in a single tile

[vonVile]

ONI does need optimization when it comes to loading/saving games. I know my computer isn't the fastest and the game plays just fine. The problem is waiting forever to load a game after 1000 cycles. This wasn't a problem before all the DLC. Klei does need to compress the save files. If I remember correctly they were around 20 megs each at 1000 cycles the last time I looked. They should be around 5 megs max.

[SGT_Imalas]

13 hours ago, vonVile said:

ONI does need optimization when it comes to loading/saving games. I know my computer isn't the fastest and the game plays just fine. The problem is waiting forever to load a game after 1000 cycles. This wasn't a problem before all the DLC. Klei does need to compress the save files. If I remember correctly they were around 20 megs each at 1000 cycles the last time I looked. They should be around 5 megs max.

Save file size is mostly determined by the amount of total entities in the game, each of which gets serialized/deserialized.

this includes buildings and tiles(!), which is why tiling large areas will blow up both ram consumption and loading times.

I have a testing world which exists in two states, one is fully tiled up, the other has huge vacuum pockets; late game world; the vaccum version brings the game to 12gb ram usage and takes ~30 seconds to load, the tiled up version eats 30gb of ram and takes ~10 minutes to load

[_Galllex_]

On 3/2/2025 at 8:50 PM, SGT_Imalas said:

not how stuff works

oni runs primarily single threaded, all those extra cores just sit there idle and decrease the total cpu load value.

still, 23 fps at cycle 700 on the best gaming cpu currently existing suggests you have some severe performance hogs in that colony, I had 60fps stable at cycle 2000 on a 5800X3D at x3 speed, the 9800X3D should have much more performance than that.
 

steps you can do to increase performance:
- install FastTrack
- remove any atmo suits
- seal off large areas with a single row of tiles and vacuum out the center (dont fill the area with tiles, thats worse than vacuum and will murder your loading/saving times; if you add doors, make them locked, door permissions alone are insufficient)
- consolidate debris into a single tile to minimize the amount of debris items (pathfinding is the biggest contender for eating performance)
- remove ladders to areas where you dont need them (pathfinding ^^)
- remove multi paths to areas (more than 1 way for a dupe to reach a certain tile; eg. with tons of ladders)
- reduce critter count
- confine critters in a single tile

OMG! Thank you very much for the idea of this mod "FastTrack". In fact, I updated the BIOS and the FPS increased to 30-40 in the middle of the colony, but after installing the mod I got 75 FPS!! On other asteroids and the top/bottom of the main asterois is 85-100 FPS at 3th speed. What a pleasure!

CPU load 25-40%. When the camera moves the frequency can drop to 30 FPS.  It seems that there were fewer freezes on Intel than on AMD - maybe it's a driver problem. But on 11900K I disabled E-cores in the task manager every game, otherwise FPS dropped by half. And these saves are a headache! Why can't they happen in the background?

Regarding other points - I have a lot of stairs and floors, because the whole asteroid is evenly divided. As well many farms and greenhouses. I want to have a dream asteroid, not concreted tunnels in a vacuum. The Dream asteroid - this is what the developers should implement. Maybe they should borrow the ideas of this mod.

[SGT_Imalas]

13 minutes ago, _Galllex_ said:

I updated the BIOS

do you have XMP profiles enabled?

ram runs very slowly without those

 

14 minutes ago, _Galllex_ said:

- I have a lot of stairs and floors, because the whole asteroid is evenly divided.

you dont necessarily have to remove all of them (or vacuum out the map), those are just optimisations.
what you should consider is removing multi-paths (ways for duplicants to go to a location on more than one way), since those are rather bad on pathing calculations and can be removed without losing direct access

[cyberwarlord]

14 hours ago, SGT_Imalas said:

Save file size is mostly determined by the amount of total entities in the game, each of which gets serialized/deserialized.

this includes buildings and tiles(!), which is why tiling large areas will blow up both ram consumption and loading times.

I have a testing world which exists in two states, one is fully tiled up, the other has huge vacuum pockets; late game world; the vaccum version brings the game to 12gb ram usage and takes ~30 seconds to load, the tiled up version eats 30gb of ram and takes ~10 minutes to load

Can confirm, lost a 8k+ days save because the vacuum failed over a whole planet without me realizing it. Was still loading and running smooth on my potato pc with 40 dupes till that happened.

Will load but crashes, out of memory exception or something soon as you unpause. Tried the oldest save but I can't fix it in game fast enough without sandbox. 

[_Galllex_]

21 hours ago, SGT_Imalas said:

do you have XMP profiles enabled?

ram runs very slowly without those

actually no, three days I can’t find a solution for the DDR5 to work on the XMP 6000 MHz. MB drops the frequency to 4800 MHz. I have never used AMD and didn’t think it would be a problem.

[SGT_Imalas]

apparently it is an issue with certain mainboard manufacturers for am5
 

never had an issue with it on am3+ and am4

[_Galllex_]

36 minutes ago, SGT_Imalas said:

apparently it is an issue with certain mainboard manufacturers for am5
 

never had an issue with it on am3+ and am4

finally, I found a tiny check-box "apply XMP" and ran 6000 MHz. I can’t say that it had a big impact. Maybe plus 5-10 FPS. It doesn’t matter, because the FPS still can fall quite suddenly.

[Gurgel]

What I do not quite understand is why the saving does not just do essentially a memory image copy and then serialize stuff on that with other cores. Is this an engine limitation?

[DolphinWing]

13 hours ago, Gurgel said:

What I do not quite understand is why the saving does not just do essentially a memory image copy and then serialize stuff on that with other cores. Is this an engine limitation?

While I'm not familiar with Unity's internals, I can share a relevant experience from developing an Android app for our hardware few years ago. The app had a significant delay in displaying the saved history list upon startup/restart. Initially, we attributed this to CPU performance limitations. When we began planning a next-generation hardware, I was tasked with porting the app. This provided an opportunity to investigate the history list loading delay. It turns out someone stored the entire binary hash map data to a file when app close. When the app starts, It reads the hash map binary and took very long time to convert it back to what we can use it the program. The original implementation contained other numerous errors in managing the history data. So I opted to rewrite the entire system using JSON serialization. After replacing the history management with my JSON-based implementation, the app startup time improved dramatically. While I can't definitively pinpoint direct memory operations as the source of the problem, but it indeed give me bad impressions. I think if we can serialize and deserialize the data ourselves, don't use direct memory copy because you don't know if they added extra overheads. Fully review the serialization and deserialization routines may be another way to potentially mitigate performance issues.

[Gurgel]

The copy is because it is much faster and hence the "world" would need to be stopped for a much shorter time. 

[imazined]

It would basically double the RAM requirement while saving.