search

scp-fs2open / fs2open.github.com

Origin Repository for SCP FreeSpace 2 Open
https://www.hard-light.net/
Other
406 stars 162 forks source link

Performance hit upon subsequent mission replays #2961

Closed MitoPL closed 3 years ago

MitoPL commented 3 years ago

Recently I have noticed, that replaying the Icarus cutscene causes the FPS to drop considerably. Here are my results from three subsequent plays, launching the mission through "continue campaign" and then replaying it through "replay mission" button in the debriefing.

05-12-2020, 20:19:41 fs2_open_20_1_0_20201001_39d77d8_x64_SSE2.exe benchmark completed, 16972 frames rendered in 178.406 s

                 Average framerate  :   95.1 FPS
                 Minimum framerate  :   48.0 FPS
                 Maximum framerate  :  123.9 FPS
                 1% low framerate   :   45.4 FPS
                 0.1% low framerate :   21.3 FPS

05-12-2020, 20:22:49 fs2_open_20_1_0_20201001_39d77d8_x64_SSE2.exe benchmark completed, 14889 frames rendered in 179.469 s

                 Average framerate  :   82.9 FPS
                 Minimum framerate  :   49.3 FPS
                 Maximum framerate  :  120.3 FPS
                 1% low framerate   :   46.3 FPS
                 0.1% low framerate :   25.4 FPS

05-12-2020, 20:25:57 fs2_open_20_1_0_20201001_39d77d8_x64_SSE2.exe benchmark completed, 14232 frames rendered in 176.687 s

                 Average framerate  :   80.5 FPS
                 Minimum framerate  :   48.2 FPS
                 Maximum framerate  :  120.7 FPS
                 1% low framerate   :   44.5 FPS
                 0.1% low framerate :   21.7 FPS

The benchmarks were made with MSI Afterburner, with a version of the software no more than a couple weeks old. As you can see, the FSO version used is 2020-10-01 nightly. Hardware specifications are: Ryzen 7 4800H with 16GB of single channel 3200MHz memory with an RTX 2060 Mobile (I believe it's the refreshed version). There was no throttling of any sort. Also my observations of the performance statistics suggest that there is a considerable CPU bottleneck at play.

Also, important note: the first and third runs happened to experience the issue where the Karuna model stops colliding with beam weapons after destroying a specific turret on it, so I assume that the actual average FPS results would have been ever so slightly higher in these two runs if not for this bug.

This might also suggest that FSO performance is constantly degrading between mission replays, and this performance degradation is being removed if you restart the game. This might be feasible given some vague reports of people restarting FSO after longer game sessions to restore decent FPS levels.

z64555 commented 3 years ago

Performance loss over time would seem to indicate some sort of memory fragmentation of frequently used files, or possibly a memory leak which slowly consumes more resources over time.

This doesn't appear to be a bug that can tracked easily, for me at least. We'll need a solid set of benchmarking tools to monitor the FPS as well as the memory being used, and if there's some script that'll loop a mission indefinitely all the better.

MitoPL commented 3 years ago

After some discussions on Discord, I have decided to provide some additional data points here. Debug log of a different three Icarus replays run, with frame time tracing on: log

A bunch of screenshots of frame time tracing statistics: First run: 1, 2, 3, 4, 5 Second run: 1, 2, 3, 4, 5 Third run: 1, 2, 3, 4, 5

z64555 commented 3 years ago

Ok, uhm. One thing we can probably do is get some sort of memory tracker, along with a fragmentation tracker for things like bmpman.

MitoPL commented 3 years ago

While I have not made a lot of research into the matter, cursory playthrough of Solaris suggests that the mod is really prone to similar performance issues accumulating over time. Might be a decent test subject later on.

JohnAFernandez commented 3 years ago

I may have just gotten a lead on this. ~900 objects were deleted on the first run through Icarus on my machine, and then 2000 on the second run. Something's going on.

JohnAFernandez commented 3 years ago

I don't think that one ended up being related. (Although it was a great bug to fix!)

JohnAFernandez commented 3 years ago

Ah, okay, according to @PhantomHoover , this slowdown is caused by LUA's garbage collection. That sounds to me like something we can't fix.

z64555 commented 3 years ago

Would you please quote him here, for record keeping? "It's the garbage collector" is a rather simplified explanation.

Goober5000 commented 3 years ago

Ah, okay, according to @PhantomHoover , this slowdown is caused by LUA's garbage collection. That sounds to me like something we can't fix.

We could explicitly call the garbage collector whenever we load a mission.

JohnAFernandez commented 3 years ago

We could explicitly call the garbage collector whenever we load a mission.

That wouldn't affect scripts that have Visual Novels or things in-between missions like that?

His quote is https://discord.com/channels/223511295431933953/223511391531827200/866275698933760000

"yeah. i tracked that down to the lua garbage collector in the end (i think)" Not sure if by "I think" means that he is having trouble remembering or if he wasn't completely sure about it.

Goober5000 commented 3 years ago

That wouldn't affect scripts that have Visual Novels or things in-between missions like that?

Axem's visual novels didn't start until after the mission had finished loading. So no, it shouldn't interfere with them. It might interfere with scripts that run during the mission load, but I don't think any such scripts exist. And players are used to the game being occasionally unresponsive during load anyway.

Goober5000 commented 3 years ago

Please test the PR at #3635 - either by checking out and building, or running the attached build - and see if it helps.