PC Fix the memory leaks!

Np! I use it frequently when I'm experimenting with personal programming project I use in learning lol. I am bad with causing memory leaks sometimes... You can use it mid-game, but likely wont clear 7 days memory allocations because it's still running. But, in personal conjecture, if the game is done with the particular address it may clean it up. Definitely will after you close the game. Hmm... let me look up for windows 10, I am curious.

Mixed results on 10, but if it doesn't throw an error should work. Looking at my old IT book, it should work for windows 7 too.

I should add there's a 64 bit version too I forgot for reasons of sleepy.

Code:
 %windir%\SysWOW64\rundll32.exe advapi32.dll,ProcessIdleTasks
There's been debate of course, it works or it is bull♥♥♥♥, but I've always found it works. Also works when (recently used) the game keeps crashing due to a particular memory refrenece error. Ran this and had my friend run it and game ran like a charm after.

 
Last edited by a moderator:
Yeah, converting to the Unty engine wasn't an easy task for them, why it took so long. They have been fixing memory leaks, indeed, they;re better off than others (like Rust...). Honestly I don't see any memory leak issues unless playing on a large server, there are some serious leakage there. Playing co-op with another person doesn't seem to do it either unless a crash happens. I've heard of people running out of ram with 32GB in the early alpha days of Rust, and I'm not running bad with 8GB on this game. Hell, SWTOR has worse memory leaking and it's a AAA game (although it's complete garbage atm). They're doing fine. There is a trick you can do... I think this will work just the same on Windows 10 to clear out garbage on your ram. Right click desktop, create new shortcut. Add this to the target:
Code:
%windir%\System32\rundll32.exe advapi32.dll,ProcessIdleTasks
Name it whatever you want. It will do nothing on your screen, as it's just doing a ram clear which happens in less than a second typically. May need to run as Admin.
A couple of things....

1. There was no converting to the Unity Engine. The game has been on Unity since it started.

2. That's also not why a17 took so long. It's been clearly stated multiple times that the upgrade mid-cycle from Unity 2017 to 2018 had almost zero impact in development. The only thing affected was the work of some texture artists.

3. 8GB RAM is kinda the minimum requirement for a17. If you want to play it well, you'll need over 12.

4. When you have only 8GB RAM, anything running on your system that isn't the OS, is getting in the way of the client because it needs a minimum of 6GB all to itself.

5. Even easier to clean up your RAM on Windows is to make two VBS files.

Boost1.vbs

Code:
FreeMem=Space(409600000)
Boost2.vbs

Code:
Mystring=(7300000000)
Put them on your desktop and run one after the other. Works on 7 through 10.

 
I run decent enough on 8GB, but I am aware I need more lol. Going to build a new rig once I save some money up from college. I strip Windows down of bloatware stuff and disable desktop and all of that. I am on windows 8, uses quite a bit less than 10. Thanks for posting that, that's very nice. Good to know!

I'll be damned. Well, use that folks =p It ran slightly quicker than the other one I had going.

 
I think part of the problem [and I have nothing to back this up] may be the Unity update.I only say this because other developers are having a difficult time adjusting as well.

Someone even mentioned a game rolling back to Unity 2017 because they just couldn't make it work.
As Sylen mentioned, the Unity update didn't delay TFP in releasing A17, but yes, I have previously mentioned that another developer, that for Empyrion Galactic Survival, eventually rolled back their Unity update during their Alpha 8.7.1 release, stating:

Hi Galactic Survivalists,

 


Unfortunately, we had to revert the game engine back to Unity 2017 because several internal crashes and problems appeared after the Unity 2018 upgrade.


 


These game-engine related problems were almost impossible to find during the closed tester and Experimental phase and showed up only after the public release when a high number of players were playing the game on different machines.


 


We decided to do this step to be able to entirely focus on the upcoming Alpha 9 release and not be distracted by hunting these internal Unity 2018 bugs.


 


Be assured that we will revisit the Unity 2018 upgrade after the Alpha 9 release. The efforts we have invested into the Unity 2018 upgrade were not in vain because we can quickly re-integrate the Unity 2018 related changes after the Alpha 9 release. We will then again need your help in finding these nasty bugs.


 


Sorry for the inconveniences during this rough week with Unity 2018 and thanks for your understanding & patience.


So, clearly, it wasn't a trivial task, even if TFP handled it so well it didn't delay them, it did delay others.

 
So, clearly, it wasn't a trivial task, even if TFP handled it so well it didn't delay them, it did delay others.
They "say" it didn't delay them but come on.

Anyway, that doesn't get us any further in determining the situation regarding memory leaks, but at least it's informative.

 
They "say" it didn't delay them but come on.
Anyway, that doesn't get us any further in determining the situation regarding memory leaks, but at least it's informative.
Well, we can all only take TFP at face value (or not I guess for the more cynical types). Memory leaks can be real PITA's to find, so no doubt there'll always be some of them around, but equally, I'm sure TFP work to squash the bigger ones, even during experimental phases, since if the game became unplayable generally, well, no-one could do much testing.

I expect though, we'll have to put up with some level of leaky memory through to Beta.

 
Memory leaks can be real PITA's to find...
Yeah and that's politely understating it.

The only thing worse is fixing someone's sloppy, un-commented code.

Well.... maybe they are tied for hair pulling frustration.

5z5D1DK.gif


 
Yeah and that's politely understating it.
The only thing worse is fixing someone's sloppy, un-commented code.

Well.... maybe they are tied for hair pulling frustration.
Back during my own programming days, I was a prolific commenter, precisely because I'd been in positions of having to debug someone elses uncommented code. It's about as fun as having root canal without anesthetics, while being forced to watch Soccer, listen to the Spice Girls, wear a Safari suit, and be filmed for a "reality" TV documentary.

 
Back during my own programming days, I was a prolific commenter, precisely because I'd been in positions of having to debug someone elses uncommented code. It's about as fun as having root canal without anesthetics, while being forced to watch Soccer, listen to the Spice Girls, wear a Safari suit, and be filmed for a "reality" TV documentary.
Haha yeah had some similar experiences.

I was fortunate enough to have an older brother [with OCD] who taught me from the age of ten to code neatly.

"One line of code - one comment."

He'd say it over and over.

He was right though. Anyone having to dig into his stuff had an easy time of it.

 
Last edited by a moderator:
Back during my own programming days, I was a prolific commenter, precisely because I'd been in positions of having to debug someone elses uncommented code. It's about as fun as having root canal without anesthetics, while being forced to watch Soccer, listen to the Spice Girls, wear a Safari suit, and be filmed for a "reality" TV documentary.
Yup. Can confirm the amounts of fun as described in my debugging section of my recent course with uncommented and broken code lol. Python wasn't as bad, but C# was just ridiculas lol. Least Python I could read it as English if the code was typed erroneously and without comments. C# was like... what you said lmao. I guess it had something to do with I was just learning C# without knowing C and just Python and some Java/SQL. I discovered why the author of my Python book said that you'll one day find yourself rocking back and forth asking a rubber duck why you're going insane.

 
<snip>

3. 8GB RAM is kinda the minimum requirement for a17. If you want to play it well, you'll need over 12.

4. When you have only 8GB RAM, anything running on your system that isn't the OS, is getting in the way of the client because it needs a minimum of 6GB all to itself.
Hey SylenThunder , question for you if I may,

At beginning of experimentals I posted about -low- memory use; every A17x build has stayed under 4GB RAM usage, even when playing 3+ hours. <--see Edit at bottom

MadMole replied asking why anyone would want the game to use more memory.

With more than average time spent spec'ing hardware and tuning *Nix performance & TCP/IP stacks, I've never run into a situation where _reducing_ memory swaps wasn't a performance gain. To be clear I'm not just talking about the dreaded, swap to disk.

Now I've no way of knowing what MM meant exactly, could be good things like streamlined code, removal of un-needed libraries, etc. But when I've thought about it the last couple of weeks, I'm honestly wondering if A17 isn't using _enough_ memory? Recalling I specifically upgraded this old box to 16GB RAM during A16, and it seemed to help performance a bit.

And sure, my old potato w a 1GB gpu is running almost all lowest vid settings, and that may be why it's not using >4GB. Yet it's kind of hard to wrap my head around A17 being ~2GB stingier w memory than A16.

The part I colored blue in your post is what I'm _not_ seeing here.

Win7 64-bit, 16GB RAM. b221. Verified that the 64-bit version is running via task manager.

Appreciate any light you can shed on this for me :)

Edit: just scanned log from earlier today where I had game running for 4+ hours. Was teleporting around looking at potential build sites in Nav, doing some mining, building, had a wandering horde, etc. RAM -did- go over 4GB for resident set size.

--a few minutes in;

"2018-12-16T09:54:34 878.975 INF Time: 14.28m FPS: 35.03 Heap: 1372.8MB Max: 1396.3MB Chunks: 240 CGO: 196 Ply: 1 Zom: 1 Ent: 2 (6) Items: 0 CO: 1 RSS: 3280.2MB"

--just prior to log out;

"2018-12-16T15:01:10 19274.186 INF Time: 253.93m FPS: 29.79 Heap: 1483.2MB Max: 1545.9MB Chunks: 306 CGO: 195 Ply: 1 Zom: 0 Ent: 1 (25) Items: 0 CO: 1 RSS: 4535.8MB"

 
Last edited by a moderator:
It's because of a couple of things.

1. It's Experimental and non optimized, so some things use more memory than they need to.

2. Larger textures require more RAM. Now if you're playing on minimal settings, with the lowest texture resolution option, you aren't going to see this. On medium settings the game client will use 2.5GB just loading to the menu screen. It will use more as world data is loaded.

3. The log doesn't show the total RAM the client is using.

In the test I just ran, the client is showing 3179.8MB used. Which matches closely with the Privately allocated RAM. However the client is committing 6308.3MB of RAM from the system. Some of that can be shared with other processes if they need it, but it's reserved for the client to expand.

Now as I explore this new world, the private increases a little bit to 4224.6. The Commit on the other hand, has now increased to 8289.5.

This is just from moving around and making it load more textures.

Now if I toss some SI calculations into the mix, the Commit increases even more. If the commit exceeds the amount of physical address space you have in RAM, it will start using your pagefile on the slow HDD.

Also note, I did this testing in Navezgane with no Zed spawns. With Z's it's going to use a bit more RAM. RWG may increase it also.

 
It's because of a couple of things.
1. It's Experimental and non optimized, so some things use more memory than they need to.

2. Larger textures require more RAM. Now if you're playing on minimal settings, with the lowest texture resolution option, you aren't going to see this. On medium settings the game client will use 2.5GB just loading to the menu screen. It will use more as world data is loaded.

3. The log doesn't show the total RAM the client is using.

In the test I just ran, the client is showing 3179.8MB used. Which matches closely with the Privately allocated RAM. However the client is committing 6308.3MB of RAM from the system. Some of that can be shared with other processes if they need it, but it's reserved for the client to expand.

Now as I explore this new world, the private increases a little bit to 4224.6. The Commit on the other hand, has now increased to 8289.5.

This is just from moving around and making it load more textures.

Now if I toss some SI calculations into the mix, the Commit increases even more. If the commit exceeds the amount of physical address space you have in RAM, it will start using your pagefile on the slow HDD.

Also note, I did this testing in Navezgane with no Zed spawns. With Z's it's going to use a bit more RAM. RWG may increase it also.
Yes..... very in depth analysis.

4jzZPXL.gif


Actually kidding aside, that was helpful.

 
Optimization phase is for Beta typically. You can't do much optimization if you're going to release a bunch of balancing/changes/content that will break the optimization you just did. You can, but doesn't make sense.
This is correct. Especially when they've just updated to a new version of the Unity engine. That means that most of the optimizations they had to do for the old engine are likely lost and they had to start over. Performance optimization is a slippery slope because no matter how much you tweak things, there will always be a group who have problems running your game. More often than not its due to people not fully satisfying recommended system specifications, but devs get yelled at in forums when they tell people to upgrade their PC when that is the EXACT solution to the problem in a lot of these cases. Some people just feel that they can run a potato but still should be able to get 60FPS on maximum graphics while simultaneously watching Netflix on a second monitor while rendering some 3D art in the background so they can upload it to DeviantArt once they are done complaining on the forums about how the game's performance is substandard.

 
The memory leaks are definitely an issue that I look forward to being fixed. I have enough ram that it doesn't have much of an affect on me but my wife suffers hard due to the leaks. After a little bit of playing she has to shut the game out, and sometimes restart the computer, to recover.

 
In A16.4 I had issues with memory leaks, but it's MUCH worse in A17 experimentals. I used to be able to run the game for hours before running low on memory, but the memory leaks are worse than ever with each update. Now I can barely run the game 30 minutes without having the restart the game. I'm only running 8GB of RAM, but players shouldn't be required to have 16GB just to avoid crashing every hour or less. This is something that has been affecting the game for years now, and it's only getting worse with each subsequent patch.
I'm sure TFP are aware of this, since it's nothing new, but it's time to at least make a statement or something. Love the game, but y'all have got to do something about the memory leaks. I'm not running much of anything in the background, only using about 1.5GB when not gaming, and it's not like I'm running the game using high settings. Could we at least get a statement regarding the memory leak issues?
Weird, I have 16GB of RAM and have no issues playing for 19 straight hours. The game requires more now than before mos tlikely as the game east 9GB of RAM on max settings. Like it always has for me anyway... Yeah the standard these days is 16 for a reason btw.

 
It's because of a couple of things.
1. It's Experimental and non optimized, so some things use more memory than they need to.

2. Larger textures require more RAM. Now if you're playing on minimal settings, with the lowest texture resolution option, you aren't going to see this. On medium settings the game client will use 2.5GB just loading to the menu screen. It will use more as world data is loaded.

3. The log doesn't show the total RAM the client is using.

In the test I just ran, the client is showing 3179.8MB used. Which matches closely with the Privately allocated RAM. However the client is committing 6308.3MB of RAM from the system. Some of that can be shared with other processes if they need it, but it's reserved for the client to expand.

Now as I explore this new world, the private increases a little bit to 4224.6. The Commit on the other hand, has now increased to 8289.5.

This is just from moving around and making it load more textures.

Now if I toss some SI calculations into the mix, the Commit increases even more. If the commit exceeds the amount of physical address space you have in RAM, it will start using your pagefile on the slow HDD.

Also note, I did this testing in Navezgane with no Zed spawns. With Z's it's going to use a bit more RAM. RWG may increase it also.
-Really- appeciate you taking the time to respond Sylen :loyal:

I just captured mem use info for both; Textures=Half w TreeQual=Middle & Textures=Full w TreeQual=High

well, what I could using Task Manager and Resource Monitor, heh

Now I'm remembering why I've steered clear of trying to tune Windows :)

The first pic actually includes the blood moon restarting, as I'd logged out after horde ended but prior to 04:00 game time.

I went ahead and killed all the z's, then flew around a little bit, then took the capture.

Textures=Half w TreeQual=Middle



Second pic only in game a minute, flew around a bit, took capture.

Textures=Full w TreeQual=High



Just so there's no confusion, I'm by no means disagreeing w anything you said :)

And I'll completely agree that Windows ~ Unix are not birds of a feather, so it's on me to do some learnin' up (gah!).

Again, thanks for taking the time!

Edit: oops. To clarify, Textures @ Half & TreeQual @ Middle are my 'defaults', 1600x900.



 
Last edited by a moderator:
Yeah, I'm running with basically everything on full at 1920x1080 except V-Sync, SSOA, DOF, and Sun Shafts.

 
Yeah, I'm running with basically everything on full at 1920x1080 except V-Sync, SSOA, DOF, and Sun Shafts.
Someday... :) (i'm just being stubborn about the vid card prices)

Had a thought (oh oh) :) Wonder if some of the mem use difference is related to GPU mem buffering? I'm running an ancient 1GB card, imagine you're running 6GB+

No matter really, I'm just happy that I can still play 7dtd on this old dog; i5-2500k, 6850 1GB, 128GiB SSD

1600x900 still gets ~22 fps indoors, ~30s outside & >50 down in the mines. Not to shabby for an 8+ year old box that wasn't bleeding edge when I built it, heh.

 
Back
Top