View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0023421 | AI War 2 | Bug - Other | Jul 18, 2020 5:18 am | Jul 20, 2020 7:00 pm | |
| Reporter | NRSirLimbo | Assigned To | Chris_McElligottPark | ||
| Severity | major | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.101 Connection Status: Confirmed | ||||
| Fixed in Version | 2.102 Digression For Quality | ||||
| Summary | 0023421: Performance Leak in Engine_Universal_OnUpdateFromMainThread? | ||||
| Description | While testing out my modified Marauders I had a massive performance drop. Performance analysis shows that Engine_Universal_OnUpdateFromMainThread is using almost 3.5 million ticks, I'm guessing that's what slows things down? Also I've tested with all threads of the modified Marauders (LRP, Stage 2, Stage 3) being not executed (return as 1st statement), the drop in performance still occurs, so I'm guessing it's an issue with Vanilla. Modified Marauder mod (required to load this) and a savegame appended. Note that it will pop up a "We've lost" screen on start because during the test Marauders destroyed the Human homeworld. This may or may not be the cause of this, at least this performance drop didn't occur at the same time the player died. | ||||
| Tags | No tags attached. | ||||
| related to | 0023405 | resolved | Chris_McElligottPark | Memory leak lead to 13GB ram used followed by crash |
|
|
|
|
|
If you turn on the more detailed performance tracking in the debug menu, what sub-section of that is using so many ticks? It might be as simple as the thread being flooded with actors, or it could be something else. Your savegame size suggests that it's not too many entities. I can look at this, and this seems in line with the potential memory leak mentioned elsewhere, so it is probably in my code. But having it narrowed down so I can focus on multiplayer would definitely be a win. |
|
|
I'm afraid I have absolutely no idea how to interpret these tick values. Also, from what Puppet Master reports this happened after repeated loading/saving, the savegame here instantly slows down after loading. I'm not sure if these are the same issue. I will see what else I can find out, and what ships are doing in the escape screen info. |
|
|
I'll add that I do not know if that was the cause, mealy that it is something I did during a long session that a memory leak could have been any part of. By long I mean, too long. ;) |
|
|
Encountered it again. Here's the data. |
|
|
I am 99&% sure that you were seeing the same thing as 0023405. It was one of those "how did this ever work" sort of bugs. Basically the timer based pools were not actually pooling, just stacking up more and more. So I would expect anything and everything to grind to a halt after enough play. If you see it again, please let me know, but given how very broken this one thing was, and how central that is, I can't imagine that this would be something else at the moment. On the subject of ticks: 1. One millisecond is 10,000 ticks. 2. All of the kind of stack-trace-y method names are telling you how many ticks they took, INCLUDING all of their children. So it's a lot like a general performance profiler in that regard. 3. The various BG, SIM, and display threads don't run in sync with one another, so high ticks on one doesn't really block the number of ticks on another. This is definitely the part that gets tricky, because it's basically multithreaded profiling all in one view... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Jul 18, 2020 5:18 am | NRSirLimbo | New Issue | |
| Jul 18, 2020 5:18 am | NRSirLimbo | File Added: MarauderRework_V0.9.zip | |
| Jul 18, 2020 5:18 am | NRSirLimbo | File Added: 20200718032912_1.jpg | |
| Jul 18, 2020 5:18 am | NRSirLimbo | File Added: s2.save | |
| Jul 18, 2020 5:18 am | NRSirLimbo | File Added: s2.savemet | |
| Jul 18, 2020 10:30 am | Chris_McElligottPark | Note Added: 0057681 | |
| Jul 18, 2020 10:57 am | NRSirLimbo | Note Added: 0057683 | |
| Jul 18, 2020 11:43 am | Puppet Master | Note Added: 0057684 | |
| Jul 19, 2020 8:05 pm | NRSirLimbo | File Added: 20200720020324_1.jpg | |
| Jul 19, 2020 8:05 pm | NRSirLimbo | File Added: 20200720020336_1.jpg | |
| Jul 19, 2020 8:05 pm | NRSirLimbo | File Added: 20200720020339_1.jpg | |
| Jul 19, 2020 8:05 pm | NRSirLimbo | Note Added: 0057691 | |
| Jul 20, 2020 6:57 pm | Chris_McElligottPark | Relationship added | related to 0023405 |
| Jul 20, 2020 7:00 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Jul 20, 2020 7:00 pm | Chris_McElligottPark | Status | new => resolved |
| Jul 20, 2020 7:00 pm | Chris_McElligottPark | Resolution | open => fixed |
| Jul 20, 2020 7:00 pm | Chris_McElligottPark | Fixed in Version | => 2.102 Digression For Quality |
| Jul 20, 2020 7:00 pm | Chris_McElligottPark | Note Added: 0057725 |
