I took a look at the profiler when running my game and I can watch a whole bunch of stuff there - but not my scripts' memory usage. Thing is, my game's total mem allocation is 223 MB, but the textures are only 112 of this and one or two MB that I see except for that. I have no clue where my other 100 MB memory went and I would like to optimize my scripts a bit. Side note: I code using Visual Studio. Maybe I should look there?
Here are a few memory profiling tips I have learned from shipping apps in Unity.
GC ALLOC
In the CPU Usage view of the Unity Profiler window you can see how much memory your script allocated in any given frame. This is shown in the GC Alloc (Garbage Collection Allocations) column.
This won't give you the total memory usage of a single script, but it is very useful for improving performance and memory consumption. If your scripts are allocating every single frame, memory will continue to accumulate until the Garbage Collector gets triggered. This accumulation will increase your memory footprint and running the GC will cause a performance hit.
See here for more info: https://docs.unity3d.com/Manual/ProfilerCPU.html
Memory View
The Detailed Memory View of the Unity Profiler Window tells you the memory usage of anything loaded in the game (including lots of built-in assets). This will let you identify which textures, meshes, or other assets are overly large. When you look at an asset in this view it tells you where it is referenced in your scene, which can help you identify which game objects may be using too much memory.
One problem with this view is that many assets show up as a blank because they don't have a name. This is happens when you create assets (textures, meshes, etc.) in script. You can change this by setting the .name property of any asset you create. This will then show up in the memory profiler window.
See here for more info: https://docs.unity3d.com/Manual/ProfilerMemory.html
Build Report
After you perform a build (Standalone, Windows Store, etc.) a build report is generated in the editor log. It can be hard to find, but it provides a lot of good information on what assets are contributing to your build size. One thing to remember is that this report uses uncompressed asset sizes, so many types of assets (textures in particular) will actually end up smaller than it shows here. In the upper-right corner of the console window, there's a drop-down menu for opening up the Editor logs. The part you are interested in will look something like this:
Textures 0.0 kb 0.0%
Meshes 0.0 kb 0.0%
Animations 0.0 kb 0.0%
Sounds 0.0 kb 0.0%
Shaders 18.6 kb 0.4%
Other Assets 0.7 kb 0.0%
Levels 5.2 kb 0.1%
Scripts 460.8 kb 10.2%
Included DLLs 3.9 mb 89.1%
File headers 8.4 kb 0.2%
Complete size 4.4 mb 100.0%
Used Assets and files from the Resources folder, sorted by uncompressed size:
18.9 kb 0.4% Resources/unity_builtin_extra
4.0 kb 0.1% ...UnityEngine.UI.dll
1.8 kb 0.0% ...UnityEngine.Networking.dll
0.1 kb 0.0% ...UnityEngine.Advertisements.dll
0.1 kb 0.0% ...UnityEngine.Purchasing.dll
0.1 kb 0.0% Assets/TestClass.cs
0.1 kb 0.0% Assets/MemoryTester.cs
0.1 kb 0.0% Assets/Rotator.cs
For the lazy, there is a Unity addon in the asset store that can parse this for you: https://www.assetstore.unity3d.com/en/#!/content/8162
(I have neither used this addon nor endorse its use)
System.GC.GetTotalMemory
If you are developing on a Windows Desktop PC you can ask the system for the amount of memory it thinks is allocated for your app using System.GC.GetTotalMemory(...). The actually number it reports may not be of interest to you, but if you place calls to this function at various points in your app you can see when total memory usage goes up. For example, you might put a call to GetTotalMemory before a large block of initialization and then again at the end of the initialization. Comparing the two numbers give you an estimate of how much your memory grew*
*It may not be totaly accurate because there are processes going on in the background, like GC, that can affect this number
See here for more info: https://msdn.microsoft.com/en-us/library/system.gc(v=vs.110).aspx
Hope some of this helps!!
Related
I have a GPU with the total memory of 6 Gb. However, around 500 Mb (or 400 Mb) is always in use (see the screenshot below) prohibiting me to exploit that portion of memory for my own needs. How to release that memory, so I would have available all 6 Gb for myself?
My app in Unity3D reports itself as quite small - 11.3M total (it's a simple game) including music and textures.
Textures 1.5 kb 0.0%
Meshes 0.0 kb 0.0%
Animations 0.0 kb 0.0%
Sounds 6.3 mb 55.8%
Shaders 406.5 kb 3.5%
Other Assets 82.8 kb 0.7%
Levels 28.6 kb 0.2%
Scripts 558.1 kb 4.8%
Included DLLs 3.9 mb 34.8%
File headers 9.5 kb 0.1%
Complete size 11.3 mb 100.0%
However, the iOS build when I upload to TestFlight is 236M, and downloading a quarter of a gigabyte for a simple game is not ideal (it's a non-dev build with no symbols).
Can anyone suggest where I start to tackle this? Every article I can find focuses on reducing your asset sizes, but mine are already small, so something else is going on.
Go:
Assume, there are 10 threads running in parallel to compress the 100 MB of data each. For each and every thread going to compress 100 MB of data. I am using zlib compression to compress the data.
Consider one process took nearly 2 sec to compress the 100 MB of data. So What happens if all the threads running parallel to compress the data.
And also i need clarification about Memory allocation for each thread.
Case 1:
having 1 GB RAM memory, Now the 10 threads going to run parallel to start the compression means , Whether it will take all the RAM Memory for the process of compression?
10 Threads * 100 MB = 1000 (Approx)
zlib itself will need a relatively trivial amount of memory, up to 256kb per thread. This will be dominated by the memory you use to store your input and output, if you are keeping those in memory. For details, see the
zlib web site (Look for the "Memory Footprint" topic).
I'm trying to get a handle on memory usage of my ASP.NET MVC4 / EF5 web application through dotMemory profiling. I'm still confused by what I see, but one thing that concerns me is the large difference in memory between running a profile on IISExpress and WebDev.
At start up, IISExpress shows (* Actually this jumped each time I killed the process and started up the profiler again):
Total: 352.3 MB
Heap Gen 0: 242.7 MB
Heap Gen 1: 3.1 KB
Heap Gen 2: 31.5 MB
Whereas WebDev:
Total: 180 MB
Heap Gen 0: 3 MB
Heap Gen 1: 148.2 KB
Heap Gen 2: 24.6 MB
This application is hosted on IIS 7.5 so which should I trust? And why does my managed memory go down after a snapshot? This is especially true with IISExpress.
Also I'm having a hard time finding what are real issues I can impact. Things tend to boil down to EF or AutoMapper and I don't see how I can avoid iterator allocation in entity linq queries and CreateMaps, etc. (http://blog.jetbrains.com/dotnet/2014/07/24/unusual-ways-of-boosting-up-app-performance-lambdas-and-linqs/)
What am I not seeing?
Edit
Memory Traffic snapshot -- String is the largest consumer
Lots of byte allocated from using AutoMapper's CreateMap -- any possible remedy?
Heap Gen 0: 242.7 MB
This is a specific thing of IIS to have a very huge Gen 0 heaps
And why does my managed memory go down after a snapshot? This is especially true with IISExpress.
dotMemory forces garbage collecting on getting snapshot (this is how MS profiling API works)
Also I'm having a hard time finding what are real issues I can impact.
I would recommend to check if a picture of the memory consumption correlates with a picture "in your head". Check top 5-10 types which objects consumes the greatest amount of the memory. Look at top objects exclusively retains memory. Check an app on memory leaks - all objects are released after a particular activity finishes.
If you don't see any very unusual, maybe you do not have to do anything.
I developed a J2ME application for s60 device. I used the memory monitor of sun wireless toolkit
to monitor memory size consumed during the execution of my application. I found that
memory size consumed reaches 126 KB. I wanted to know what is the standard memory size
consumed by J2ME applications? In other words, what is the optimum or acceptable memory size consumed
by the execution of J2ME applications. In order to compare and evaluate my application's
memory consumption according to standards.
I do not think there are any standards concerning memory consumption. Memory consumption depends on the nature of the app and amount of data it works with. There are too major concerns regarding memory - running of out it and/or too much GC activity (too frequent and/or taking too much time).
Given the fact that heap size is typically at least 1 MB on non-smartphones, and on S60 heap size is limited only by free memory, then with your 126 kB (top consumption as you say) you are more than fine and quite far from OutOfMemoryError :), and I guess there is also low GC activity because only a small part of heap is used and thus there is little pressure to run gc...