[1.4.0] GCMonitor 1.4.8.0 - A graphic Memory monitor (Marsh 9th 2018)

[Blacks]

digging in unity site seeking various information, my eye spot this

http://answers.unity3d.com/questions/64331/accurate-frames-per-second-count.html

o7

[sarbian]

Is there a problem with the current FPS display ?  The one you linked is the one that does not go under 25fps that Squad was using.

[nerf_hurrdurr]

Sarbian, I'm having a weird issue, hoping you might be able to point me in the right direction.

I've got two versions of KSP running on my computer at the moment. I can get your mod to work properly in 1.0.5, but not in 1.1. The issue is with the Memory Usage staying stuck at 0 MB.

Log file for reference.

Thanks

[Blacks]

KSP build id = 01250 x64
GCMonitor v1.4.1.0 it seams to be broke in 1.1.1
If Game start fresh GCM is fine BUT if is load any save (ALT + F9 or Load from SpaceCenter) it will happen what you see in print screen

logs: https://drive.google.com/file/d/0B9RK2PFOUhe3S3RRWXpNbTFOZFU/view?usp=sharing

Update: this issue it appear only if UI Scale: 90% & 80% > if i set to 100% GCM value are set correctly on screen & if Scale it goo biger 120 ... then value position is move to right soo UI Scale it influence position

Cheers

Edited April 29, 2016 by Blacks

[sarbian]

1.4.2

- lowered the memory usage to 84B per frame with the counters displayed and about 900B per frame with the window open. I don't think I can get it much lower.

1.4.3

- fix the app scale moving the counters

Download : GCMonitor-1.4.3.0.zip

Edited May 1, 2016 by sarbian

[MerlinsMaster]

I don't know if this has been asked already, but why are there two memory amounts on display?  

[sarbian]

9 hours ago, MerlinsMaster said:

I don't know if this has been asked already, but why are there two memory amounts on display?  

Indeed it was

 

[Padishar]

On ‎04‎/‎09‎/‎2014 at 9:27 PM, sarbian said:

1.4.2

- lowered the memory usage to 84B per frame with the counters displayed and about 900B per frame with the window open. I don't think I can get it much lower.

Are you sure you didn't mistype this comment or change something drastic in 1.4.3?  I'm sitting in the main menu on a machine that only manages 20fps and with the graph open I see virtually no garbage being generated.  The difference between the window being open and closed is only 4-8 KB every second (with just this and my own MemGraph mod running there is approx 28KB of memory allocated per second).  This is much lower than I expected as 20fps * 900B = 18 KB for your window.

However, if I show the fps overlay (and only the fps value, the memory ones are fine) then this jumps a huge amount to between 700 and 1000 KB per second (and this is clearly visible in your graph as well as mine).  I've had a quick look at the code but I can't see anything obviously wrong.  I didn't dig into the ConcatFormat stuff because the graph window uses it too and doesn't suffer from the problem.

Edt: Incidentally, I've now released the MemGraph mod here:

 

Edited May 9, 2016 by Padishar
Link to MemGraph forum thread instead of github

[sarbian]

Strange. I may have left some debug code. I'll have a look on Monday when I am back 

[Padishar]

42 minutes ago, sarbian said:

Strange. I may have left some debug code. I'll have a look on Monday when I am back 

Even stranger, when I was testing it further last night on my decent machine (i7-4770K, GTX560ti, Win64, limited to 60 fps) I was seeing a large amount of memory allocated just having GCMonitor installed without ever having opened the window (and the mem/fps thing disabled in the settings).  E.g. with just my mod at the main menu I was seeing between 130 and 200 KB/s but when I installed GCMonitor as well the usage went up to ~1800 KB/s.  Again, this is much higher than the 900B and/or 84B per frame would imply and both causes of memory use were closed anyway.

Do you happen to know if GC.GetTotalMemory(false) ever returns a smaller number than the previous time it was called when no collections have happened in the interval?  I presume not and I didn't see any when I had some logging in my mod.  Obviously, Mono doesn't return a very accurate number for total memory, it's always a multiple of 4KB for a start.  It looks like it is actually returning the total of all the pages that have anything used in them.  So, if you call it, allocate something small on the heap and then call it again, then it will often return the same value the second time.

One really "interesting" thing I found was that the other vessels in a save do have a really big impact on memory allocation rate.  I have a save containing 4 reasonably large stations (2 of 300+ parts and 2 of 700+) and flying one of these "obviously" results in a considerable rate of memory allocation (e.g. anywhere from 8 to 18 MB/s) so I launched a Kerbal X to a ~200 km orbit and deorbited the booster but the memory allocation rate was still at 5 MB/s.  I restarted the game a number of times and went back to the, now very simple, vessel and it was still doing 5 MB/s.  I then created a copy of the save and terminated the 4 stations and when I then flew the simple vessel the allocation rate was "only" a couple of hundred KB/s.

[Corovaneer]

Can it plot frames per second too?

[Padishar]

53 minutes ago, Corovaneer said:

Can it plot frames per second too?

If this is a question then, no, it doesn't plot fps on the graph but it does have the ability to show a little HUD with fps and/or 4 memory related numbers on screen.  Hit Mod-F to toggle the display or click the Config button in the main graph window and play with the options.

If it was more of a request then you may get a more favourable response (or any response at all) if you word it a little more politely...

[Corovaneer]

1 minute ago, Padishar said:

If this is a question then, no, it doesn't plot fps on the graph but it does have the ability to show a little HUD with fps and/or 4 memory related numbers on screen.  Hit Mod-F to toggle the display or click the Config button in the main graph window and play with the options.

If it was more of a request then you may get a more favourable response (or any response at all) if you word it a little more politely...

It was not a request, just a question about functionality. Thanks for the answer.

[ibanix]

Did the changes in 1.4.2 or 1.4.3 use things that are only possible in KSP 1.1.1 or KSP 1.1.2? Because GCMonitor 1.4.3 + KSP 1.1.0 (still on it for mod/bug reasons), causes this:

 

[EXC 18:54:56.863] MissingFieldException: Field '.GameSettings.UI_SCALE_APPS' not found.

[EXC 18:54:56.880] MissingFieldException: Field '.GameSettings.UI_SCALE_APPS' not found.

[EXC 18:54:56.897] MissingFieldException: Field '.GameSettings.UI_SCALE_APPS' not found.

[EXC 18:54:56.913] MissingFieldException: Field '.GameSettings.UI_SCALE_APPS' not found.

[EXC 18:54:56.931] MissingFieldException: Field '.GameSettings.UI_SCALE_APPS' not found.

[EXC 18:54:56.947] MissingFieldException: Field '.GameSettings.UI_SCALE_APPS' not found.
 

Plus GCMonitor just not working (Alt-F1 doesn't work, monitor doesn't show anything, etc)

[Padishar]

Just now, ibanix said:

Did the changes in 1.4.2 or 1.4.3 use things that are only possible in KSP 1.1.1 or KSP 1.1.2? Because GCMonitor 1.4.3 + KSP 1.1.0 (still on it for mod/bug reasons), causes this:

Yes, it accesses the stock UI scaling info that Squad added in 1.1.2.

[MalevolentNinja]

Since a portion of this whole GC issue rests on the shoulders of mod makers, is it possible to somehow identify which mods are creating the most garbage?

With 64 bit KSP we have now it's pretty easy to say "oh I'm gonna install ALL the mods I ever wanted!" only to run smack into huge GC stutters.

 

 

[Padishar]

31 minutes ago, MalevolentNinja said:

Since a portion of this whole GC issue rests on the shoulders of mod makers, is it possible to somehow identify which mods are creating the most garbage?

With 64 bit KSP we have now it's pretty easy to say "oh I'm gonna install ALL the mods I ever wanted!" only to run smack into huge GC stutters.

As far as I'm aware, there are basically two ways to do it.  Either you use this mod (or an alternative similar mod such as MemGraph, linked in my sig) and simply test with different combinations of mods to see which cause the highest rates of memory allocation, or you can run the game under the Unity profiler which should be able to give, at least, some indication as to which DLLs are responsible (though to get more accurate information would probably require rebuilding the mod DLLs including debug symbols).

[MalevolentNinja]

15 minutes ago, Padishar said:

As far as I'm aware, there are basically two ways to do it.  Either you use this mod (or an alternative similar mod such as MemGraph, linked in my sig) and simply test with different combinations of mods to see which cause the highest rates of memory allocation, or you can run the game under the Unity profiler which should be able to give, at least, some indication as to which DLLs are responsible (though to get more accurate information would probably require rebuilding the mod DLLs including debug symbols).

Sure, I know I could add mods one by one to see if any were serious offenders. I guess I was attempting to politely ask for a feature request.   Something like Windows task manager showing all the loaded mods and their memory allocation.

Is it even possible to list this out in game on a per dll basis? Without recompiling everything to include debug symbols I mean.

[Padishar]

7 minutes ago, MalevolentNinja said:

Is it even possible to list this out in game on a per dll basis? Without recompiling everything to include debug symbols I mean.

No, even recompiling everything with debug symbols wouldn't enable a mod to do that.  You would need to be running a modified version (or at least a debug version) of mono and would probably need to make some significant changes to it before that would be practical (i.e. less hassle to implement than the trial and error method would be to use).

[MalevolentNinja]

That's not the answer we were hoping for   But I do appreciate the expert info!

[Padishar]

6 hours ago, MalevolentNinja said:

That's not the answer we were hoping for   But I do appreciate the expert info!

Actually, on linux and, possibly, OSX (any version that uses a shared library version of libgc), it should be possible to write a mod that talks directly to libgc to get more detailed information.  This may require making some modifications to libgc (e.g. to add some sort of hook that would allow code to be run every time any memory is allocated on the heap) but this would probably be rather easier than delving into the whole of Mono.  Of course, adding this sort of detailed memory allocation tracking would make the game run an awful lot slower and is basically what the Unity profiler does already so you may as well just use that.

Another complication is in deciding whose "fault" a particular allocation is.  If a mod calls a KSP function that allocates a lot of memory on every frame then is it the fault of the mod or of the KSP function.  Some functions in KSP are not intended to be called on every frame so that would be the mod's fault and some functions are intended to be called often but still create far too much garbage which would be KSP's fault.  So, to be a really useful tool, it would probably need to record (a substantial part of) the call stack for every memory allocation rather than just the actual function doing the allocation or the function from the "top-most" DLL involved.  This would cause the game to run even slower still...

[MalevolentNinja]

1 hour ago, Padishar said:

Actually, on linux and, possibly, OSX (any version that uses a shared library version of libgc), it should be possible to write a mod that talks directly to libgc to get more detailed information.  This may require making some modifications to libgc (e.g. to add some sort of hook that would allow code to be run every time any memory is allocated on the heap) but this would probably be rather easier than delving into the whole of Mono.  Of course, adding this sort of detailed memory allocation tracking would make the game run an awful lot slower and is basically what the Unity profiler does already so you may as well just use that.

Another complication is in deciding whose "fault" a particular allocation is.  If a mod calls a KSP function that allocates a lot of memory on every frame then is it the fault of the mod or of the KSP function.  Some functions in KSP are not intended to be called on every frame so that would be the mod's fault and some functions are intended to be called often but still create far too much garbage which would be KSP's fault.  So, to be a really useful tool, it would probably need to record (a substantial part of) the call stack for every memory allocation rather than just the actual function doing the allocation or the function from the "top-most" DLL involved.  This would cause the game to run even slower still...

Good info. As far as the compounding slow downs, that's not really an issue if you look at this as a debugging tool. You would only run it when needed.

But overall, it sounds like way more effort than just trying mods one by one to see if there are any serious offenders.

[MircoMars]

love the tool, thanks for the effort. just one thing:

could you please make repositioning more comfortable. I think the +/- 1 pixel is handy and shouldn't be replaced, but either a slider or a box to punch in values would be great for rough placement. 

[sarbian]

4 hours ago, MircoMars said:

love the tool, thanks for the effort. just one thing:

could you please make repositioning more comfortable. I think the +/- 1 pixel is handy and shouldn't be replaced, but either a slider or a box to punch in values would be great for rough placement. 

Try with your other mouse button

[MircoMars]

5 hours ago, sarbian said:

Try with your other mouse button

will do, thanks