View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0022262 | AI War 2 | Bug - Gameplay | Nov 22, 2019 12:27 pm | Dec 13, 2019 1:44 pm | |
| Reporter | deo | Assigned To | BadgerBadger | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.010 Extracting Those Archives | ||||
| Fixed in Version | BETA 1.015 Testing The Outguard Waters | ||||
| Summary | 0022262: Simulation performance degrade way too much | ||||
| Description | playing 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 | ||||
| Tags | No tags attached. | ||||
| related to | 0022353 | resolved | Chris_McElligottPark | Game breaking bug - Friendly Marauder |
|
|
|
|
|
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. |
|
|
yea, i just did as you said, thanks |
|
|
The "before nano" save runs at 100% for me. 1.save runs at about 55% for me. It's worth noting that 1.save 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. |
|
|
i have 40% sim sped now with 2x speed and process consumes 80% cpu, i'm afraid it's closer to max power |
|
|
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 |
|
|
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). |
|
|
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 |
|
|
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. |
|
|
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: timingReference.StartRememberFrame(); timingReference.FinishRemembering(); 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. |
|
|
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? |
|
|
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). |
|
|
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 |
|
|
Oops, sorry about that. My bad remembering. Good to know about marauders. |
|
|
This was a performance problem related to marauders |
|
|
huge improvement in 1.015, thanks |
| 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: 1.save | |
| Nov 22, 2019 12:27 pm | deo | File Added: before nano.savemet | |
| Nov 22, 2019 12:27 pm | deo | File Added: before nano.save | |
| Nov 22, 2019 12:31 pm | deo | Description Updated | |
| Nov 22, 2019 1:11 pm | Chris_McElligottPark | 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 | Chris_McElligottPark | 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 | Chris_McElligottPark | Note Added: 0054777 | |
| Dec 4, 2019 8:19 pm | BadgerBadger | Note Added: 0054824 | |
| Dec 5, 2019 10:30 am | Chris_McElligottPark | Note Added: 0054829 | |
| Dec 6, 2019 5:07 pm | BadgerBadger | Note Added: 0054873 | |
| Dec 6, 2019 5:11 pm | Chris_McElligottPark | 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 |
