unity editor grows memory usage. from 1gb ram to 3/4/5gb in few hours as I use the editor

any advice? i think these are meshes but not sure

(as the usage grows, unity becomes slower and i need to restart it)
screens from playmode stopped




advise me brothers!! is that meshes? what to do?

Are you sure the slowness and memory usage are related? Does your computer have an extremely small amount of ram?

1 Like

While it’s possible it’s a memory leak Unity can be very memory hungry at times. With how many assets you have in that project I’m surprised you’re not seeing far more than a few gigabytes. I just started a build process and Unity went from a few gigabytes to nearly 13 GB. After completion it only dropped back down by a gigabyte.

We have been having this conversation over here:

https://discussions.unity.com/t/789511/22

1 Like

Sometimes my UnityEditor process takes 12~ gb of RAM.
The only thing that worked for me is restarting it and also adding more RAM to the PC.

1 Like

Unity has terrible memory management. Pretty much useless. It tends to accumulate, as more often more playmode are executed. It is like duplicates all asset to memory when entering play mode and forgetting to release them, when exiting play mode. I experienced that with many/all Unity versions, don’t know how far back in time.

Opening editor and scene less than GB. Run first time, 1+GB. Next play mode close to 2 GB. And keeps growing. Closing and reloading Unity releases memory. Just as discussed in the link above by others.

When memory reaches 85% total utilisation, it starts moving stuff to virtual memory. Which obviously may hinder performance at runtime. Depending how much virtual memory you have. I got 16GB, which doubles my DDR mem.

1 Like

uh why wont they fix it then. it also seems suspicious to me, the memory keeps growing from 1gb to 5gb+ (to me at 5gb i decide to shut it down) as you keep entering the playmode. but theres no benefit

maybe they do not know about this?

Just tried this with Unity 2021.1. A new project (URP template) had memory usage around 1.1GB. Hitting Play for the first time saw memory usage increase to 1.4GB. Hitting Stop once the numbers had stabilized saw memory usage decrease by around 40MB.

Once the numbers had calmed down I repeatedly entered and exited Play mode with additional time spent waiting for stabilization. Memory usage was nearly identical to the first time entering and exiting play mode. That is to say it only increased and decreased by 40MB each time with the highest usage being 1.4GB.

Or maybe it’s not as simple as it’s being made out to be. Unity is a very complex beast and when you introduce both official and third-party editor extensions it only becomes worse.

Windows will not deallocate all memory just because a application stops using it. So it can be false positive memory leaks too. Just saying

3 Likes

I don’t know, maybe it is the combination of assets, packages. Specially with preview. Alpha and Beta may also affect. Even tho, I am experiencing that in pre LTS, like 2020.1.151f.

It is weird and can be annoying.

Yeah I agree.

When memory usage decreases it often ends up fragmented. Small areas of memory remain in use, with unused memory in between. You can think of it similar to how an HDD gets fragmented after file additions and deletes, except Unity can’t just defragment its in use memory like you can an HDD with the defrag tool. So if you’re still using just 1 byte of memory of a page, the entire page remains allocated.

Also, my understand is Unity is pretty lazy about memory deallocations anyways, to avoid reallocating memory again the next time you need it.

4 Likes

Building on what @Joe-Censored has said, indeed, you can’t just move allocated data around in memory, because then anything which points to it would break.

If I allocate 1000mb of data, and then deallocate 900mb of it, the 100mb still in use could be scattered throughout the 1000mb the OS gave to the application. That doesn’t mean that the application is “leaking”, it means that it’s been allocated more space than it is currently using. If it’s keeping track of that internally and re-uses the empty space before requesting more from the OS then it’s not “leaking”. In fact, it’s working fairly effectively.

An actual “leak” is when an application isn’t tracking its internal memory correctly and loses track of free(able) memory it has already been allocated. As a result it can’t use all of that free memory and just has to keep asking the OS for more.

I’m a glass-half-full kind of person, so I’d say that it’s “aggressive about reuse” rather than “lazy about deallocation”. :wink:

There are a few good reasons to do things this way, including avoiding some of the fragmentation previously mentioned.

2 Likes

Memory fragmentation is an interesting topic because it’s not as simple as it appears to be. When the OS allocates memory to an application it’s not giving the application the physical location but rather it’s giving the application a virtual address that then itself points to a physical address.

Virtual addressing exists to make software development easier. With virtual addressing if two applications try to access the same location it’s perfectly fine because it’s not truly the same location but is instead two different locations in physical memory.

Which is where the fun begins. What may look like a contiguous block of memory to the application is often a very fragmented layout in physical memory due to both applications and background processes constantly starting, allocating memory, processing data, and then closing freeing memory.

Some reference material below. Ignore that one of them is for Arduino. It had good illustrations.

https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals
https://cpp4arduino.com/2018/11/06/what-is-heap-fragmentation.html

2 Likes