Late Game Lag Kills this Game

[Cilya]

3 hours ago, Draquila said:

"Premature optimization is the root of all evil." If you write clean, modular code, you can optimize it later; no sense wasting your time optimizing something that will need 10 rewrites anyway.

It makes sense. However, it's not true that you can still optimize later. Performances hits due to design problems may be really hard to solve later. It might be a good idea to start profiling your program early to have an idea of causes problem now or what may cause problems later. The real problem with premature optimization is when the programmer is optimizing before profiling. Not when the programmer is optimizing before releasing the software, which is probably a good behavior.

For us player, there is no way to say if the ONI programmers did a good job optimizing or not optimizing. Even for those of us which looked at the disassembled code. We just do not have enough information. How are they working ? What are they talking about ? What are their plan ? We just can't judge their work.

However, my guess is that they already did a lot of optimizations. I loaded a save from last year, which used to be unplayable at normal speed : I had to use the "super slow debug mode" for the game to run smoothly. With the current version of the game, it can run at normal speed and even at higher speed. They did improve that.

I believe a lot of code added to the game each patch doesn't require optimization ; optimization is probably needed on a few hot spots. For instance, I have a high latency when opening the priority and the consumable window. It's only a table for 40 duplicants, it shouldn't be so long to open. There is probably something going wrong there, and it is not too early to solve it : this window is probably going to stay until release.

A lot of people blamed the physic simulation for being responsible for slowness. However, this simulation had been already optimized. For instance, it has been compiled to binary code, thus removing the overhead from the .NET layer. I've tested much larger maps (with Onion Patcher) for which the simulation was fast. So, as pointed out by many, the problem is more likely due to individual items dropped on the floor and inside containers. And I'm sure it has already been optimized at this point.

[Draquila]

5 hours ago, Cilya said:

It makes sense. However, it's not true that you can still optimize later. Performances hits due to design problems may be really hard to solve later. It might be a good idea to start profiling your program early to have an idea of causes problem now or what may cause problems later. The real problem with premature optimization is when the programmer is optimizing before profiling. Not when the programmer is optimizing before releasing the software, which is probably a good behavior.

True. Core systems like temperature should definitely be optimized ASAP.

As you said, I think a lot of the performance hits right now are debris. I have a 400-cycle base with debris everywhere that chugs at 20-30 FPS on triple speed, and has been below 40 FPS since at least cycle 200, but a ~250 cycle base that still runs at a perfect 60 FPS because I built a lot more storage compactors.

[BlueLance]

15 minutes ago, Draquila said:

True. Core systems like temperature should definitely be optimized ASAP.

As you said, I think a lot of the performance hits right now are debris. I have a 400-cycle base with debris everywhere that chugs at 20-30 FPS on triple speed, and has been below 40 FPS since at least cycle 200, but a ~250 cycle base that still runs at a perfect 60 FPS because I built a lot more storage compactors.

I spose debris would probably be why my game gets horrible eventually, because all of the regolith etc. but it isnt supposed to build up without me visiting the surface... Also I rarely used compactors and my performance was fine, except later in game, now my performance dies rather quickly.

[old_fantom]

A couple of thoughts,

(1) the clean up your debris horse has left the barn.  If you mine the entire world then start cleaning, it takes forever.  I did not start sweeping until I had nearly cleared the entire map.  

(2) premature optimization may be extra effort, but I wonder how many sales they will lose by word of mouth?  e.g. "the game is fun, but it is a dog on my machine.  It pegs my processor, makes my machine run hot, takes forever to load and the gameplay crawls" is not a ringing endorsement.  Nobody who says this is going to tell a friend, or put in a video or review, "but it is early release and you should ignore all that"  I get the point of early release, but you have to be realistic when you choose to ER your game.  

[chemie]

I hate the delay that locks everything at the start of each cycle.  By 300 cycles it is long enough (maybe 5 seconds) to be really annoying.  Since it is locked, you commands are ignored

[Kabrute]

thats the autosave chemie, my suggestion to klei is to move the autosave to just 10 seconds sooner, then its not overlapping morning pathing lag

[Albryant]

On 7/10/2018 at 9:13 AM, Yunru said:

So I haven't experienced any lag, but ONI does push my laptop into the 80+*C range D:

Perhaps an ice sculpture or two would help?

[Yunru]

On 7/11/2018 at 5:25 AM, Megouski said:

Proper

There's your problem.

"Proper" optimization is... inefficient for actually optimizing.

[chemie]

18 hours ago, Kabrute said:

thats the autosave chemie, my suggestion to klei is to move the autosave to just 10 seconds sooner, then its not overlapping morning pathing lag

I know it is.  I wish they would save uncompressed because the 4 mb file should not cause that kind of lag on a ssd.  Even 100mb uncompressed would save faster.

[Megouski]

Guys clearly they cannot optimize the save file until they release the game because REASONS

 

/s

[Zarquan]

I just hope that in the future they parallelize the game.  Most computers these days have at least 2 cores and a lot of the work that has to be done is almost Embarrassingly Parallel, where all of the calculations are independent of each other.  (Embarrassingly Parallel is one of my favorite CS terms, probably right behind Nibble for 4 bits (half a byte).)   Or maybe utilize the GPU for some of the thermal calculations, since it is almost an optimal problem for CUDA programming. 

Of course, it is probably best that they make the game feature complete before they do this.  For all I know, all the thermal stuff is going to change in a patch or 2.

[Cilya]

It seems to be already parallelized. How do you know it's not ?

[BlueLance]

27 minutes ago, Cilya said:

It seems to be already parallelized. How do you know it's not ?

If by that you mean it is multi cored then ate to break it to you but it aint XD 

It has been spoken about and tested by plenty of people

[abud]

9 minutes ago, BlueLance said:

If by that you mean it is multi cored then ate to break it to you but it aint XD 

It is dominating all my cores, and still not multi cored?

 

Spoiler

 

[babba]

What is find frustrating is that storage containers constantly get filled by dupes, although they are already 99.99% full.

Dupes running around loading 5 gramm, 2 gramm or even milligram !!!

Whats the point with text flying from containers "1 milligram of iron", as dupes add these insane tiny amounts of material to a container.

Its tiresome to constantly set lots of full containers to priority 1.

As a player has 50,100 or 500 of full containers, its container micromanagement.

From my point of view it would be great to be able to build a dump truck size container,

a large skip size container...Which could contain 1000 ton`s of material.

 

Cores:

Its a single core game, it runs best on intel turbo boost cpus ( 6700k 7700k 8700k or i9 series ).

Get a single core to run as fast as possible and ONI is your friend.

People get confused as the Windows taskmanager shows load on all cpus/cores in the graph.

[Lutzkhie]

devs should update the hardware requirement of this game, according to steam it only requires a dual core CPU which will surely make your FPS crawl at some point

[babba]

The more cores you have...the slower the game - The game utilizes a single core.

An exception are Intel Turboboost CPU`s.

Running ONI & Windows ( nothing else ), i7 & i9 CPU`s clock one core at high and max GHz,

perfect for ONI.

Similar to Warthunder & Cities Skylines.

[Cilya]

On my computer it uses 60 threads and 1.5 core load in average. It really looks like it's not using only one core.

[Megouski]

11 hours ago, abud said:

It is dominating all my cores, and still not multi cored?

 

  Hide contents

 

1 hour ago, Cilya said:

On my computer it uses 60 threads and 1.5 core load in average. It really looks like it's not using only one core.

No, that is windows distributing/handingoff load across cores so one core doesn't catch fire. Windows tries to do this for *everything* unless explicitly told to use a certain core.This is different from true multi-core game rendering. 

 

If windows didn't do this, most applications/games would be on core0 causing huge issues.

 

devs should update the hardware requirement of this game, according to steam it only requires a dual core CPU which will surely make your FPS crawl at some point

This makes no sense. Performance for this game is single-core reliant. It is not going to run better on an 8 core 3hgz system than a 2core 4ghz system. You are far more likely to get to even 5Ghz on a 2-4 core cpu than an 8 core.

If you can OC a single core to higher than the rest, cool it properly and explicitly set the game to run on that core, you'll see better performance than if you used a 8 core system for the game and lower Ghz. They only selected dual core on steam because its a means to an end. Single core is delegated to very low power or cheap systems these days. You're unlikely to see a single core system with any sort of good architecture. Not because its single core, but because they dont make them in single core now. If they DID I would buy one for crazy over-clocks for games that only use one core and eat it up. 

 

[Cilya]

1 hour ago, Megouski said:

No, that is windows distributing/handingoff load across cores so one core doesn't catch fire.

It would be true if the CPU time cumulated on all core was lower than what a single core can handle. However, like I said, the cumulative consumed time is 150% of one core, thus it actually takes advantage of the presence of at least 2 cores. Theoretically, I can't even conclude that two cores are enough, as the synchronization might introduce idle time and perhaps three or more cores might contribute to increase the game computational power above that of two cores.

[UziMaster]

Switching cores around is not a free action, ONI might be doing the same calculations twice when windows switches cores. Perhaps the game does make light use of extra cores, but nothing major or too performance impacting. Or maybe it's just a fluke in how windows records the data. At any rate, while I haven't seen the tests myself, I believe them when they say the game doesn't really use multi-core. Everyone seems to get late-game slowdown rather consistently past a certain point, and the only times I hear about slowdown before this point is from people on particularly weak processors, such as one person who plays on a 2012 macbook.

Incidentally, even games that can't use multi-core at all still benefit from dual core over single core, since on a dual core processor all background processes like the OS can be shunted onto the second core, while the game can have the other all to itself. Though, the requirement is more likely due to the fact that no modern PC processor is less than dual core, even some of the oldest two-core processors could run the game (early-game, anyway)

Also GHz isn't the only part of the equation, different processors get different amounts of work done per Hz. An old AMD FX at 5GHz won't run the game as well as a dinky I3 at say, 3.7GHz. If you're looking at anything recent though, GHz and core count are a good enough metric. That's enough with the science lessons for now though

[Cilya]

6 hours ago, UziMaster said:

Switching cores around is not a free action

No, but nowhere near 50% of one core computational power. All you said is true, but it doesn't imply that the game uses only one core.

[TLW]

This game suffers from much the same issue as Dwarf Fortress (another tile-based sim). These sort of games are about the easiest to parallelize. They are very nearly embarrassingly parallel at the sim-tick level... double-buffer your game state and you're golden.

It could be simmed in parallel, with some tweaks. It would be fine if it was added incrementally. But there are so many things now that'd require tweaking that it's a major task to add it now. And it will only get worse.

This is the problem with premature optimization arguments... Premature optimization absolutely is a thing, but so is premature pessimization. Choosing architectures that look fine to start, but once you start actually trying to optimize them you realize they are infeasible to optimize to the point you want. After you've already built the majority of your game in said architecture.