View Issue Details

IDProjectCategoryLast Update
0022262AI War 2[All Projects] Bug - GameplayDec 13, 2019 1:44 pm
ReporterdeoAssigned ToBadgerBadger 
Status resolvedResolutionfixed 
Product Version1.010 Extracting Those Archives 
Fixed in VersionBETA 1.015 Testing The Outguard Waters 
Summary0022262: Simulation performance degrade way too much
Descriptionplaying on 100 planet map and simulation usually at lvl 50%, may drop to 30, sometimes runs at 100
there is one almost dead AI left and most of the map taken by nanocaust which i believe is a real reason for slowness
before i released it and it started to take planets i just never seen any speed degradation
i have two saves one (named "1") is when nanocaust taken the world
second is before releasing it (it's on Null Ought planet)

i have core i7, load usually at 50-70% for the "1" save and about 30% for one before releasing nano
TagsNo tags attached.


related to 0022353 resolvedx4000Bughunter Game breaking bug - Friendly Marauder 



Nov 22, 2019 12:27 pm


before (1,844,575 bytes)
before nano.savemet (56 bytes) (4,143,936 bytes)
1.savemet (56 bytes)


Nov 22, 2019 1:11 pm

administrator   ~0054678

One thing you can do to offset it is just hit the + key a couple of times, and it will run at fullspeed again. We'll have to investigate the specific slowdowns to the simulation, but in general this is the way around it as a workaround at the very worst. Running at 30% of the speed of 3x (300%) speed = 100% speed.


Nov 22, 2019 1:22 pm

reporter   ~0054679

yea, i just did as you said, thanks


Nov 22, 2019 1:22 pm

manager   ~0054680

The "before nano" save runs at 100% for me. runs at about 55% for me.

It's worth noting that is 26 hours in and AIP is at 1200 and it looks like the nanocaust has conquered almost every planet. Late game situations with a ton of stuff happening is exactly where you would expect to get performance issues, and it still seems very "playable" (especially since you can win the game whenever you want to).

I think "way too much" is a bit strong. I don't really have any issues with the game being a bit slow right before you win, especially since you can just crank the simulation speed up.


Nov 22, 2019 1:24 pm

reporter   ~0054681

i have 40% sim sped now with 2x speed and process consumes 80% cpu, i'm afraid it's closer to max power


Nov 22, 2019 2:16 pm

reporter   ~0054682

well, if you say its ok, then it's ok :D but slowdowns began way before i reached "almost win" state, and i guess it depends on galaxy size
if you have 55% when whole 100 planet galaxy is nanocausted, then with 300 planets galaxy slowdown become issue when only 33% of galaxy taken


Nov 22, 2019 2:21 pm

administrator   ~0054683

One piece of clarification: increasing the 2x speed or 3x speed or whatever WILL speed up the simulation, but won't make the percentage show as higher. The percentage is based off whatever your intended target is. So running at 2x 40% speed means it is running at 80% actual speed instead of the intended 200%. It doesn't mean you just moved from 30% to 40% or whatever the numbers are.

If you moved that to 3x, it would still say 40%, but you'd be running at 120% of baseline speed (40% of the 300% you asked for).


Nov 22, 2019 4:57 pm

manager   ~0054684

Chris, would any of your performance stuff help me figure out what about the nanocaust is making things super slow? Or would I just need to look at the code and see if there are any obvious inefficiencies


Nov 22, 2019 6:04 pm

manager   ~0054685

I've made some minor performance improvements to the Nanocaust, but I suspect it's the sheer number of ships in the game that is dragging things down.


Dec 2, 2019 4:58 pm

administrator   ~0054777

I would instrument it with things like this:

            Engine_Universal.NewTimingsBeingBuilt.GetOrAddTiming( FramePartTimings.TimingType.BackgroundSimThreadSubItem, "YourMethodOrCodeAreaNameHere" ).StartRememberFrame();

and then later call:

            Engine_Universal.NewTimingsBeingBuilt.GetOrAddTiming( FramePartTimings.TimingType.BackgroundSimThreadSubItem, "YourMethodOrCodeAreaNameHere" ).FinishRemembering();

You can do this with very little overhead in the main, although if there's someplace where it will be calling the same method millions of times then this will be definitely quite inefficient and give you false positives.

In those cases, you'd want to do this:

FramePartTimings.Timing timingReference = Engine_Universal.NewTimingsBeingBuilt.GetOrAddTiming( FramePartTimings.TimingType.BackgroundSimThreadSubItem, "YourMethodOrCodeAreaNameHere" );

Then hang onto that as a static reference, or whatever you want -- maybe only call that if it's not already null.

Then calling these have almost no overhead:


That's the best way to figure out where there are performance problems. It's extremely accurate, and adds almost no overhead in general in most cases.


Dec 4, 2019 8:19 pm

manager   ~0054824

I'm sure this is a really dumb question, but how do I see the performance numbers generated by adding those lines to my code?


Dec 5, 2019 10:30 am

administrator   ~0054829

Oops! I should have clarified that, sorry. If you go into the escape menu (make sure and hit spacebar after going in there so that it keeps running the game), then you'll see all the timings written out down below if you scroll down a bit.

It's telling you in raw ms how long is being spent on things per interval of time, and it's all relative, so just looking at parts of your code in that branch versus other parts of code in the same branch is the way to go. Other things are on other threads and might not be too relevant in terms of how long they take. And the drawing of the performance data itself makes the UI as a whole look like it is heavier than it is (the escape menu is actually kind of a costly menu in terms of CPU time, surprisingly, although not enough to block anything or make things slower on most machines when it is open).


Dec 6, 2019 5:07 pm

manager   ~0054873

Actually, the best place to see this is by right-clicking the Time Elapsed In Game in the bottom left.

It does look like Marauders are a bigger time sink than desired


Dec 6, 2019 5:11 pm

administrator   ~0054874

Oops, sorry about that. My bad remembering.

Good to know about marauders.


Dec 11, 2019 7:38 pm

manager   ~0054961

This was a performance problem related to marauders


Dec 13, 2019 1:44 pm

reporter   ~0054978

huge improvement in 1.015, thanks

Issue History

Date Modified Username Field Change
Nov 22, 2019 12:27 pm deo New Issue
Nov 22, 2019 12:27 pm deo File Added: 1.savemet
Nov 22, 2019 12:27 pm deo File Added:
Nov 22, 2019 12:27 pm deo File Added: before nano.savemet
Nov 22, 2019 12:27 pm deo File Added: before
Nov 22, 2019 12:31 pm deo Description Updated View Revisions
Nov 22, 2019 1:11 pm x4000Bughunter Note Added: 0054678
Nov 22, 2019 1:22 pm deo Note Added: 0054679
Nov 22, 2019 1:22 pm BadgerBadger Note Added: 0054680
Nov 22, 2019 1:24 pm deo Note Added: 0054681
Nov 22, 2019 2:16 pm deo Note Added: 0054682
Nov 22, 2019 2:21 pm x4000Bughunter Note Added: 0054683
Nov 22, 2019 4:57 pm BadgerBadger Note Added: 0054684
Nov 22, 2019 6:04 pm BadgerBadger Note Added: 0054685
Dec 2, 2019 4:58 pm x4000Bughunter Note Added: 0054777
Dec 4, 2019 8:19 pm BadgerBadger Note Added: 0054824
Dec 5, 2019 10:30 am x4000Bughunter Note Added: 0054829
Dec 6, 2019 5:07 pm BadgerBadger Note Added: 0054873
Dec 6, 2019 5:11 pm x4000Bughunter Note Added: 0054874
Dec 11, 2019 7:37 pm BadgerBadger Relationship added related to 0022353
Dec 11, 2019 7:38 pm BadgerBadger Assigned To => BadgerBadger
Dec 11, 2019 7:38 pm BadgerBadger Status new => resolved
Dec 11, 2019 7:38 pm BadgerBadger Resolution open => fixed
Dec 11, 2019 7:38 pm BadgerBadger Fixed in Version => BETA 1.015 Testing The Outguard Waters
Dec 11, 2019 7:38 pm BadgerBadger Note Added: 0054961
Dec 13, 2019 1:44 pm deo Note Added: 0054978