Memory leak

[Crzyrndm]

(it could just be a coincidence, but it's just too suspiciously similar in my mind - got a good lead here I say).

Pretty much why I brought it up.

A bit more background now I'm at my dev PC:

Unity GUI is all one-shot. You have to redraw it every frame and as soon as you stop telling it to draw it dissapears.

The Squad GUI object that displays the extended strategy description (class: RUIScrollableRichTextArea) is not one-shot. You tell it what to draw once and it keeps drawing the same things. Now, when you tell it to change what it's drawing (in my case updating the text), the memory usage increases slightly. If you force it to draw every frame (as I was doing initally, being used to Unity GUI being one-shot.) that small increase becomes a very noticeable increase.

http://youtu.be/EUYC9vFkzlk

Because of how things are handled, while I plugged the original leak I caused, you can still force it through ^^

EDIT

YT is taking it's sweet time... (and finally...)

Edited February 27, 2015 by Crzyrndm

[AlphaAsh]

This looks very similar to a leak I accidentally caused in the past through some GUI code (Sane Strategies, that little bit of extra text on the strategies window was doing a few MB/s initially). What happened with me was that every time the element was redrawn, the old version was overwritten but not erased. Now, this doesn't happen with the base Unity Gui code, but that piece of text was written on a custom Squad class. It still leaks like mad when you switch strategies or change commitment , but it only does it when parameters change now(ie. you can force it, but thats not on me any more).

I have a feeling the tweakables suffer from something similar. Instead of drawing the same object, they are updating the object even when no changes are made and the old object is not being discarded properly.

I remember spotting that for you

KSP's GUI management is leaky as all hell right now. I couldn't say whether it's down to KSP or Unity though - I can't be bothered to analyse it more. I can only hope that Squad can recognise and treat some of the leaks that are around. And they're plentiful.

EDIT - nightingale ran into some nasty lag issues with the contract widget recently which may have some relevance to this discussion too.

Edited February 27, 2015 by AlphaAsh

[Laie]

>500ms - that's over a half second, or thirty frames, and is definitely a rather long pause. Way too long for a video game.

Let me rephrase that: if it would happen once, I'd write it off as an OS update check or something. That it repeats every few seconds points to the game itself having a problem.

[nightingale]

I remember spotting that for you

KSP's GUI management is leaky as all hell right now. I couldn't say whether it's down to KSP or Unity though - I can't be bothered to analyse it more. I can only hope that Squad can recognise and treat some of the leaks that are around. And they're plentiful.

EDIT - nightingale ran into some nasty lag issues with the contract widget recently which may have some relevance to this discussion too.

Yup, there's some pretty major issues in the KSP GUI stuff - my issue was very similar to Crzyrndm's. What would happen is that every time the contracts app gets a ParameterChange event (due to a contract parameter's state changing) it will recreate the GUI elements for the whole contract. There ends up being two problems:

1. While closed, it caches the events. When the player opens it, it rebuilds the gui elements once for each cached event. So if I update a contract parameter 100 times, the contracts app will refresh the contract GUI bit 100 times (and it tries to do this all in one frame). I've seen it lag for 2-3 minutes after leaving it closed for a while. See #3964 on Squad's bugtracker which has never been touched by anyone at Squad. I ended up having to stop firing that event, and rig up a system that waits for the contracts up to open and give it a single update event.
   
2. The GUI redraw is horrificly slow. I thought problem #1 had come back, but it just turns out that the redraw time seems to increase quadratically based on the number of parameters. Again, had to rig up additional stuff to queue up all my updates within the frame and not post them until the next frame to avoid lag.
   

Anyway, not directly related, but certainly shows that there's GUI problems related to performance/memory usage in 0.90... Only thing we can do is raise these issues on the Squad tracker and hope we hit the point soon where community reported bugs become a higher priority than new features.

Edited February 27, 2015 by nightingale
edit for clarity

[rkman]

Talking about GUI oddities, since 0.9 the main menu 'flickers' on mouse-over, and it seems to occasionally not detect clicks. Might be related to other GUI issues.

[klesh]

Using mostly the same mods from the build before .90 and the game crashes significantly more now.

The end of my KSP playing sessions are now because its the 3rd of 4th crash of the night and I don't want to sit through it loading up again, rather than being satisfied with my evening's space exploration and shutting it down on purpose.

[Wjolcz]

This thread seems to explain a lot of what happens to me in KSP.

[QPDO]

I let top run next to my 64bit KSP on Ubuntu. It starts with a Mem Usage of 50% and steps up 5% every quickload I make. Stuttering starts at about 70%. Mem Usage stays at 70% - 68% no matter if I return to KSC or Main Menu.

[John FX]

Now I have a need to make a stock game and only have sarbain's memory display mod and see what happens.

I notice, in my modded install, that a scene change makes my memory footprint jump around 20Meg until the game crashes. No scene change means no crashes. YMMV

[QPDO]

Does KSP flush certain parts of the memory at all? It seems to me that through quickloading (and to a certain extent through reverting) additional instances of the played scene are added to the memory again and again, yet the old instances are not removed. I'm curious about the outcome of John FX's test with the vanilla kss. Maybe we can pinpoint it on the ksp install or the mods.

[helaeon]

Popping in with a report of one I can reproduce very easily.

Work on craft in VAB for a bit, launch & fiddle with craft on pad (don't even turn the engines on), revert to VAB, work on craft more, and repeat. Maybe after 5 or 6 "launches" game will crash. I have a reasonably heavy mod install, but on space center after loading I'm at 1.8 GB. Using OpenGL with DDS Loader (no ATM). Have plenty of VRAM and RAM... way more than the game can use.

This is the most severe example of it, I notice the time I can play without crash is limited by craft switching as well but it's not as pronounced as VAB-Launch-Revert-Repeat.

[John FX]

So I noticed that if you start a fresh stock game (stock except for the graphical memory monitor from sarbian), go into the VAB, make a craft, launch it, revert back to the VAB, create a 'new craft' to empty the VAb then exit back to KSC which should leave you back where you started your RAM footprint increases by around 400-500Mb

I'd experiment more but stock KSP is really boring for me these days. Is there anyone who plays stock who would experiment more so we can get a more accurate picture?

EDIT :

Popping in with a report of one I can reproduce very easily.

Work on craft in VAB for a bit, launch & fiddle with craft on pad (don't even turn the engines on), revert to VAB, work on craft more, and repeat. Maybe after 5 or 6 "launches" game will crash. I have a reasonably heavy mod install, but on space center after loading I'm at 1.8 GB. Using OpenGL with DDS Loader (no ATM). Have plenty of VRAM and RAM... way more than the game can use.

This is the most severe example of it, I notice the time I can play without crash is limited by craft switching as well but it's not as pronounced as VAB-Launch-Revert-Repeat.

Hmmm. I now have suspicion about 'revert to VAB'...

[katateochi]

hmmm what's happening with the tweakable interface is very interesting.

Are memory leaks (or perhaps more the actions of the GC) responsible for the periodical short freeze that some of us are experiencing?

[QPDO]

Are memory leaks (or perhaps more the actions of the GC) responsible for the periodical short freeze that some of us are experiencing?

I'd give it a 100% if I go with the Wikipedia Definition of memory leak.

[QPDO]

Hi I was running a little test on a vanilla KSP windows 32-bit version. I made a log to keep the numbers. I will add it as a code field below.

Graphics everything off or on the left -> mem usage stable
single tests:
SM3 Terrain Shaders ON -> mem usage stable
Terrain Scatters - Scatter density 10% -> mem usage stable
Render Quality Good -> mem usage stable
AeroDyn FX LOW -> mem usage stable
Antialiasing x2  ->mem usage stable
VSync Every VBlank ->mem usage stable
Frame Limit 120 ->mem usage stable
Pixel Light Count 8 ->mem usage stable
Shadow Cascades 8 ->mem usage stable


procedural test

PLC 8
SC 8
RQL Good
SM3 Terrain ON
AeroDynFX Low
VSync On Every
AA 2x
SC 12
Terrain Detail Default
Scatter Density 50% on Terrain SCatter Off
Terrain SCatter ON
Texture Quali 1/4
TQ 1/2
TQ Full
PPFX ON
Frame Limit 60 FPS
-> stable in main menu on every step


Quit / Reload

2.052.180 -> 1min wait in main menu->2.049.384 -> Mem usage stable

Sandbox -> stable

VAB -> 2.233.176 -> 2.236.916-> about 100kb mem usage per second -> moved mouse over all parts in command pod section -> 

stable at 2.243.816 -> moved view -> rising at 100kb per sec-> stable after stopping and one minute at 2.265.412

going for launch button-> no change on mouseover of launch button
mem reduction on click down to 2.199.762 -> after loading of world and 1 min wait ->2.207.752
rotating view around command pod -> mem usage raises and stops at 2.223.752
Reverting to VAB -> 2.313.780
Leaving VAB for KSC -> 2.307.604
Back to VAB -> 2.336.012
Launch -> 2.277.944 after loading and rotating view (stable)
Reverting to launch -> 2.290.972 
EVA , walked around, boarded again-> 2.296.408
recover vessel to KSC-> 2.369.220
to SPH -> 2.380.884
launch -> 2.305.640
on runway -> 2.310.568
recover vessel to KSC -> 2.372.468
to SPH -> 2.375.984
Launch to runway -> 2.306.732
Test: Reverting to launch 3 times  -> 2.306.496 -> 2.310.704 -> 2.314.816
Zoom out to maximum -> 2.314.904
Revert to SPH -> 2.389.432
Launch -> 2.322.404 on runway
revert to SPH -> 2.395.268
Launch -> 2.324.120 on runway [feels like its leaking some MB on the editor/world transfer each time]
on runway while writing log -> 2.331.116 [game was just running in background] -> 2.327.008
recover to ksc -> 2.388.580 [16 MB more than on the last recover! seems like the amount of leaked MB during the reverts] -> 2.391.556
enter VAB and returned to KSC -> 2.392.792
enter VAB and returned to KSC -> 2.389.404
enter VAB and returned to KSC -> 2.386.408 [magical mem usage reduction]
enter VAB and returned to KSC -> 2.382.268
enter VAB and returned to KSC -> 2.362.392
enter VAB and returned to KSC -> 2.349.244 [could anyone explain that?!]
enter SPH and returned to KSC -> 2.385.792
enter SPH and returned to KSC -> 2.358.552
enter SPH and returned to KSC -> 2.344.840 [see the magic work again]
enter Tracking Station  (TS) -> 2.291.776
enter KSC -> 2.359.532
enter TS and returned to KSC -> 2.359.176
enter TS and returned to KSC -> 2.358.552
enter TS and returned to KSC -> 2.358.552 [now thats stable]
opened runway and launchpad menu once each -> 2.384.232
return to main menu -> 2.358.424 [+300MB compared to game start]

What I think I verified is, that the transition between world and editor (aka revert VAB or SPH) seems to leave some mb in the memory. Same seems to be the case on vehicle recovery.

EDIT: It's also interesting to know that bouncing in and out between KSC and the editor lowers the mem usage. Why it does though... no idea ^^

I hope this helps somebody with a little idea of the game mechanics

Edited April 2, 2015 by QPDO