If I clear up Leaked Managed Shells, then will that clear up more memory than the printed value?

[heady shore]

I have a very short time to deal with this. This is why I'm asking.
In the Memory Profiler, there's the "All of memory" category, which has a search bar. If I type "leaked managed shell", then I get multiple types of items inside "Managed -> Managed Objects". For the Allocated Size, it was writing 5 MB, but after I cleared up around 4-5 leaking static data structures, dictionaries, lists, etc., I only have around 500 KB in here.
I made multiple snapshots in the same game area, at around 0 minute and at around 10 minute. Unfortunately I made the first snapshots in Unity Editor (because of the horribly long building times), but I had around 250 MB memory increase during the 10 minute gameplay period.
Then I made the clearing, I made a build and I measured again inside a build. The memory increase during the 10 minute gameplay period got only 100 MB.
Unfortunately I'm not sure if it was caused by the clearing of leaked managed shells or it was because of the differences between editor and build snapshots, I had no time to shelve/stash the clearings and make a new build again and do 10 minute gameplay again to measure the exact same area of the game.

But my question is, could the clearing up of those leaked managed shell elements (taking up 5 MB summarized size) cause that huge change in the decreasing of the memory consumption gain? Would it worth to clear up the left 500 KB leaked managed shells?

[bright echo]

It's hard to say anything without looking at the profiler data.
It could be that these 5mb worth of managed objects were referencing some other objects that actually consume more memory and preventing them from being collected by the GC or unloaded on another occasion( like a scene load). So, when you cleared them up a lot of other stuff got cleared as well.
It could also very much be that the cleared up 100-250mb mostly consists of editor or dev/debug build only stuff. It's really hard to say anything without proper investigation.

My policy is always work from a problem down to the culprit, and in your case it sounds like you're just trying to microoptimize the memory usage without it actually being related to a real issue.

[heady shore]

because I don't know what is the real issue

its a game which constantly generating new objects, and creating object pools for those

so memory will naturally increasing and that's fine, but its increasing too quickly

and its hard to find out what is the best area to optimize

[bright echo]

The rule of thumb is: don't optimize if there is no issue. I've no clue what you mean by "I don't what is the real issue". If you don't know then why the heck are you making assumption that it's related to memory??

[heady shore]

but there is issue

the memory is increasing way too quickly

now its expected to get some kind of memory increasing, but not this much

and I don't know if the stuff gets loaded is too much OR there are unnecessarily loaded stuff

so honestly I don't know what to do to figure this out... the easy way would have been to find leaked managed shells, but I'm not sure anymore if clearing up those will really solve the issue or not

[bright echo]

Is it increasing perpetually? Or does it only increase up to some point and stops growing beyond it? Let's say after an overnight stress test of switching between random scenes.

[bright echo]

Leaked managed shells don't necessarily mean an actual memory leak. It could be temporary until the next time the reference is reassigned, which is very common in games.

[heady shore]

so, the leaks between random scenes were solved (at least for now, maybe I will need to return to that as well, because the game is still in being making)

there's a game mode, which is infinite long, and in there the memory grows constantly

I know what can increase memory in there, and some of them are valid increase, but not all of them

probably

[heady shore]

what I have seen during a week is that they were not temporary at all

the game is full of static dictionaries, lists, etc., collecting references to monobehaviors, which sometimes gets destroyed

I have cleared up at least 50 of these in the last few months (50 static data structures I mean)

at least

[bright echo]

You need to provide one access point to these lists/dicts. Then you can control the removal from these collection on objects destruction better.

For example, enforce a contract on the added elements. They should have a callback that is called on destruction and remove the element from the collection in this callback.

[heady shore]

I'm not allowed to do this much of refactorings

especially since I don't know if this is still the sources of the issues or not

@bright echo

I mean the static lists/dicts

[bright echo]

Thats not ideal.

[bright echo]

Then maybe implement diagnostic feature to measure these collections over time. + an automatic stress test over long time. If the game crashes(or at least consumes a lot more memory than expected) and the diagnostics show that the collections kept on growing, you have a solid proof/correlation of the culprit and should get a green light on implementing these changes.

Or mark your task as complete and wait until actual report of a crash or something.

[heady shore]

the main problem is that the QA wouldn't have time to re-test everything

and placing data structures into some kind of controlling class would be a huge change

[bright echo]

I don't see the correlation. You can run the stress test yourself.

Don't need to push the diagnostic changes to prod(or qa or whatever branches you have)

[heady shore]

noooo

I didn't mean that

we already know that the game crashes

that's not new

but that's not giving me greenlight to refactor the whole game

[bright echo]

But you don't seem to know when and why it's crashing.

By doing what I suggested you'll have a better understanding and proof of it that would let you implement the necessary changes.

You don't need to refactor the whole game. Just some of the relevant points in it.

[heady shore]

that's true. But maybe its faster to just disable certain things during gameplay

and check if the high amount of gain is still there

at least in the last 2 hours I could filter the possible causes

[bright echo]

"clearing possible causes" can go on forever. It's not a productive way to address an issue. The productive way is to secure reproducibility of an issue, identify the cause, then address it and confirm that it's not reproducible anymore.

[heady shore]

I know. But finding the relevant data structures would take on forever as well

multiple thousands of code lines

[bright echo]

You can start with just doing a stress test with profiler captures. One capture in the evening, one in the morning. That would reveal you all the leaks you might ever need.

Another thing you can do is make a capture of half that time or twice that time and compare them to see if it's increasing and at what rate.

[heady shore]

this is what I'm doing

although

there are new stuff added to the game I was not aware of

so that might be also the source of the issue

[bright echo]

Should always test on the same change set. Never pull changes while working on an issue

Unless they're including potential fixes. But even then it's recommended to be able to back to the previous version for confirmation.

[heady shore]

that's easy to say 🙂

since Perforce doesn't let me to change files without pulling regularly

[bright echo]

Sounds like a dev environment issue. You should be able to change files as you please without pulling anything.

The local environment is usually in your full control, so you should be able to configure that.

[heady shore]

@bright echo never mind, I figured out the reasons

[heady shore]

@bright echo absolute zero idea what is this for example

and there are a lot of similar materials with "leaked dynamically"

but I also won't have time to track back the place where I should destroy them

[bright echo]

Ah, I see.
Something probably modifies materials at runtime by calling something like renderer.material.set... or something like that. This would instantiate a new copy of the material. And since materials are assets, it is not collected by the GC even if the renderer that was using it was destroyed. It would be unloaded on scene load, but in the same scene if this keeps on happening, it would keep on accumulating. Materials are not that heavy, so you'd probably need to play for a long time for this to have an impact, but it's still a leak.

Honestly, you should take it back to whoever is responsible for this, tell them "atata, bad boy!", explain that accessing the material property creates a new instance of the material and is pretty bad, especially if it's done often, and let them fix all the places where they do it.
This is the kind of thing thta needs to be shared among the project members so that everyone knows what not to do in the future and maybe fix exiting places.

Maybe reporting to your direct superiors and letting them deal with it could be a good option too.

[heady shore]

"probably need to play for a long time for this to have an impact, but it's still a leak."

yeah, this game mode goes on for an hour

[bright echo]

By a long time I mean like days or weeks. Though I guess it depends on the rate of the leak.

[short bolt]

this is easy. you are using prefabs for fx that get spawned, and they are not recycled

very common source of leaks