Are memory errors acknowledged yet?

[LordFerret]

9 hours ago, Tyko said:

I'm running MemGraph with the 64-bit version and 32GB of RAM...Still getting the pauses. They're less frequent, but oh so annoying. The definitely become more common as I have more stuff going on (ships in space, landers landed, mining going on, etc). I'm trying to figure out if certain of the activities are more responsible for the pauses than others so I can steer clear of those activities.

I've noticed that (for me) it's not so much having more stuff going on, it's what stuff in particular that's happening at that moment. For example; Certain engines at launch seem to be the cause, perhaps the exhaust effect, but once out of the atmosphere there's very little stutter. The same with some of the planes I have; At full throttle and high velocity, I'll get stutter. I've taken the same course, steer clear of certain activities, but more often than not, if I'm to get to space with my big stuff, I am just forced to deal with it.

Oh, and, I've a 64-bit OS, running the 64-bit version of KSP with half a dozen mods (literally, 6, including Memgraph), with 8gb of memory.

 

[AlamoVampire]

I think the bottom line is, its not for Squad to fix inherent engine problems, I think it falls to the folks who MADE unity to fix the inherent engine issues.

[Moach]

sorry to say - this has nothing to do with how unity handles memory

this is a known missing step in optimization which never got done before the devs who knew about it decided to "call it a day"

 

it is so that this was most likely never intended to be a permanent solution - but since it was supposedly "just optimization", it got pushed back, and there it still remains

 

no engine on this planet can work around the fact that it was deliberately instructed to load absolutely everything in one go and hope for the best - to blame it for that is like blaming a car manufacturer for getting a flat tire on a rough country road

 

also, I don't think squad is in any position right now to do much about this (or, who knows, maybe they are...) - either way, I wouldn't count on it - and the best solution would be indeed to make a mod like I described on the previous page - anything else won't take us much further

 

 

 

[Starman4308]

1 hour ago, Moach said:

no engine on this planet can work around the fact that it was deliberately instructed to load absolutely everything in one go and hope for the best - to blame it for that is like blaming a car manufacturer for getting a flat tire on a rough country road

That is a separate issue. While it was a very questionable decision to load everything straight to RAM, that is only tangential to GC pauses, in that it causes a relatively large heap to be made, which can force more frequent GC pauses on systems without much physical memory.

[FancyMouse]

17 hours ago, Moach said:

the main problem is:  KSP loads EVERYTHING unto memory at startup - this is also why loading takes so long with a good mod collection

Did you even read the thread? This whole thread is about stutter, which is sudden noticeable pause of the game during playing, caused by a stop-the-whole-world action by GC to perform memory operations. Whether it loads everything on startup has nothing to do with GC stutter. In fact, it only improves the situation, because you avoid potential stutter caused by disk IO to load.

[Alshain]

6 hours ago, AlamoVampire said:

I think the bottom line is, its not for Squad to fix inherent engine problems, I think it falls to the folks who MADE unity to fix the inherent engine issues.

I don't think it is an inherent Unity problem.  I've never seen it, but my understanding is that it only happens with high part count craft.  Frankly, that's just the edge of the engine's limits.  I doubt Unity considers that a problem.

It's caused by garbage collection, which has to occur.  The more physics calculations in use, the more garbage there will be.  It can be reduced by well programmed code, but not eliminated.  Also, reducing it is a tradeoff.  You can either delcare your objects high scope and reuse them to prevent collection but increase persistent memory usage, or declare them low scope to decrease memory usage but require more frequent collection. In today's world, the former is usually preferred, but not always.

Edited May 18, 2017 by Alshain

[TheRagingIrishman]

KSP 1.2 is built off of Unity 5.4 and in Unity 5.5 there were a bunch of improvements regarding Mono and garbage collection and KSP 1.3 will probably be built off Unity 5.6 so that should help improve GC and therefore reduce stutter.

Edited May 18, 2017 by TheRagingIrishman
spelling

[NoMrBond]

Is this something Unity 2017.1 would fix as this (finally) has the updated mono/runtime (to C#v6 and .NET4.6.x)?

If migrating KSP up from Unity 5.4 to Unity 2017.1 would fix it, how much devtime would that take (i.e. is it realistically a possibility)?

Would updating KSP from 5.4 to 5.6.1 offer any of these benefits with commensurately lower devtime required?

[TheRagingIrishman]

28 minutes ago, NoMrBond said:

Is this something Unity 2017.1 would fix as this (finally) has the updated mono/runtime (to C#v6 and .NET4.6.x)?

If migrating KSP up from Unity 5.4 to Unity 2017.1 would fix it, how much devtime would that take (i.e. is it realistically a possibility)?

Would updating KSP from 5.4 to 5.6.1 offer any of these benefits with commensurately lower devtime required?

Unity 2017 would probably further improve gc (and I'm almost certain it will include a NET update) but seeing as it is only in beta right now, KSP 1.3 won't be built on it. Instead, 1.3 will be built on 5.6 or maybe 5.5 depending on when the update process for KSP 1.3 began.

Edited May 18, 2017 by TheRagingIrishman

[Alshain]

27 minutes ago, NoMrBond said:

Is this something Unity 2017.1 would fix as this (finally) has the updated mono/runtime (to C#v6 and .NET4.6.x)?

If migrating KSP up from Unity 5.4 to Unity 2017.1 would fix it, how much devtime would that take (i.e. is it realistically a possibility)?

Would updating KSP from 5.4 to 5.6.1 offer any of these benefits with commensurately lower devtime required?

It's not likely we will see Unity 2017.  It's the next generation (basically Unity 6), they already swapped out the engine once, they won't likely do it again for this game.  5.6 is the end of the U5 cycle, and we may get that, but I doubt any more engine updates after that.

Edited May 18, 2017 by Alshain

[NoMrBond]

Just now, Alshain said:

It's not likely we will see Unity 2017.  It's the next generation, they already swapped out the engine once, they won't likely do it again for this game.  5.6 is the end of the U5 cycle, and we may get that, but I doubt any more engine updates after that.

Unity 2017.1 is basically Unity 5.7 (a naming convention change) rather than the huge change to the technological underpinnings that was between #4 and #5

3 minutes ago, TheRagingIrishman said:

Unity 2017 would probably further improve gc (and I'm pretty sure it will included a NET update) but seeing as it is only in beta right now, ksp 1.3 won't be built on it. Updating to 5.6.1 won't take much time at all (and is what will happen for 1.3).

I'd asked about this earlier, and KSP 1.3 will be staying on Unity 5.4 (not even moving up to 5.4.4, let alone 5.6.1)

[Alshain]

4 minutes ago, NoMrBond said:

Unity 2017.1 is basically Unity 5.7 (a naming convention change) rather than the huge change to the technological underpinnings that was between #4 and #5

It's in beta now, but it will be more like Unity 6.  They changed the number scheme to differentiate between 5 and it requires a new license (or upgrade purchase).  They aren't going to use a beta, and when beta is over it will be a technical leap I'm sure.

Edited May 18, 2017 by Alshain

[TheRagingIrishman]

14 minutes ago, NoMrBond said:

Unity 2017.1 is basically Unity 5.7 (a naming convention change) rather than the huge change to the technological underpinnings that was between #4 and #5

Unity disagrees with you (https://blogs.unity3d.com/2016/12/13/unity-5-6-wraps-unity-5-cycle-whats-next-in-2017/)

14 minutes ago, NoMrBond said:

I'd asked about this earlier, and KSP 1.3 will be staying on Unity 5.4 (not even moving up to 5.4.4, let alone 5.6.1)

RoverDude disagrees with you (in our private USI devs channel)

[NoMrBond]

15 minutes ago, TheRagingIrishman said:

Unity disagrees with you (https://blogs.unity3d.com/2016/12/13/unity-5-6-wraps-unity-5-cycle-whats-next-in-2017/)

RoverDude disagrees with you (in our private USI devs channel)

I was going on discussion out of the Unity forums, /r/gamedev and /r/Unity3D where that seemed to be the general feeling, it wasn't a big discrete leap like 4-to-5, but more like a .1 iteration on existing 5.x technologies (hence my 5.7 comparison)

Unless Squad are going to make a huge late 1.2.9 pre change from 5.4 to 5.6.1 (which would invalidate most, if not all,  the current testing) and blow out the production timeline to an amazing degree, they'll probably stay on Unity 5.4 as TriggerAu confirmed earlier.

Maybe they'll move up to Unity 5.6.x later, but if KSP 1.3 was going to use 5.6 the pre-release test builds would have deployed with it surely

Edited May 18, 2017 by NoMrBond

[steve_v]

3 hours ago, NoMrBond said:

I'd asked about this earlier, and KSP 1.3 will be staying on Unity 5.4 (not even moving up to 5.4.4, let alone 5.6.1)

Oh yay, rubbish performance to continue for the foreseeable future. That leaves fixing the terrain seams as the only thing in 1.3 that even remotely interests me.

[Moach]

garbage collection issues may be just as difficult a problem for unity developers to solve as unity problems are for squad to fix

the reason is, Unity itself relies on the Mono framework (which is basically an open-source version of .NET) -- and this is in a large part responsible for some of the garbage collection process, which is actually a part of the whole compiler deal and whatnot...

it's actually hard to tell - and truth be told, I have a bone to pick with the whole concept of GC in the first place - since after you get around using such a thing, you may find that it's actually EASIER to get memory leaks with GC, and those are harder to find and fix than without! (whut?!)

 

yes, while C/C++ require you to do that stuff yourself, they also have the added benefit of that you KNOW that you have to do it, so it's rather trivial to ensure that it's done - whereas the promise of "it'll delete itself when not in use" is a horrifyingly vague one for a programmer - because now, you have things in your program that you simply "leave off" and hope that somehow the damn thing eventually gets around removing it

in most cases, GC gets it right - and no major problems result -- but see, I did not learn to program in Unity

 

no sir - back in my day, we used Flash (aaaaarrgh!) -- and son, that's how it was back then and we liked it! (no we didn't - it was excrements)

 

unity GC is relatively benign, in comparison - where flash had a habit of "assuming" you were done with something, just because you left it off with an indirect reference to be retrieved later - then it'd give you a maddening problem, where depending on luck, literally, due to the unpredictable GC cycles - it may or not remove a reference which you were actually relying on!

and when you really wanted something to go away - you had to go around and ensure all pointers to and from it were reset to "null" (another issue I have with interpreted languages, null is an invitation for disaster, as it's basically defaulting every variable to "segfault, please") - but then again, that was the icing on that cake of crap which we had for a tool back then - not only GC worked against you, you still had to go and do it's job for it! since ensuring your values are nulled for disposal is actually MORE trouble than using the convenient "delete" keyword of C++

so that was flash....   we're all glad it's over

 

anyways unity seems pretty great now, doesn't it?

 

but then again - GC in unity actually can be controlled to some degree, or even overriden in some cases - so it may be possible to optimize it such that the stuttering is reduced, but then again - there are just so many things in there that need optimization that this is really not even a very high ranking issue among them

did you know that, while the little portrait cameras appear to have a very low FPS, they actually render continuously anyways? - in fact all internal assets are loaded and fully operational when you're in external view - simply because, my brother chose to "make it work first, make it work well later"...

which was fine back when "later" was an option, I guess

 

so basically, KSP was never really optimized - because they were saving it for last, and then it was too late

the only game that's been less optimized that I can think of, is FSX - which had been built under the premise of an era when processor speeds seemed like they'd just increase forever (they actually expected by the time it was out, CPUs would be some twice as fast as the average pc is today)  - but then came the thermal barrier, and well... a liquid nitrogen tank isn't exactly what you'd call "user friendly hardware" - and the industry made the sensible decision to go for more cores, instead of faster ones

 

but mainly -- the game was never tested with anywhere close to the amount of mods we demand that it handles and damned it be if it doesn't handle them well!

it has very little cause for concern performance-wise without mods, or with a reduced set... a few mods particularly, seem to have been made with sheer disregard for the fact that computers aren't really "magic" - and have a monstrous performance overhead

also, mod-on-mod warfare interactions may also worsen the problem in absolutely unpredictable ways.... 

mod authors must be then very cautious to ensure they optimize their assets as much as they can, because it's all but guaranteed that any mod in a KSP install will not be alone in there

 

Edited May 18, 2017 by Moach