I'm trying to figure out which parts of my app consumes the most RAM on a device.
If I use the memory graph in Xcode I see many objects and their sizes, but is there a way to somehow sort them by size? Or is there another tool that can show me this?
Edit:
I am familiar with Instruments, but for some reason the Allocations and Leaks instruments give me very odd numbers and most of the allocations appear as just mallocs. It probably has to do with the fact that I'm using Intel Multi OS Engine and most of my logic code is actually written in Java. I dumped an hprof of the java heap and watched it in Android Studio, so it gave me a good picture about the memory usage in the java side. But I wanted something for the obj-c/swift side too. Instruments is not very useful in my case.
Thanks.
You can run your program using profiler (CMD+I).
Choose "Leaks" and "Allocations" inside menu.
This tool could help you to know how much memory and which objects/processes waste the most.
These articles could help:
Working with Instruments - Allocations
Profiling Memory Allocations In iOS With Instruments
Related
I can see some memory leaks in my code, if i run from the instruments. But in call tree, I'm not getting proper information about memory leak.
How can we identify and solve those kind of memory leaks .
You should look into the memory graph tool for debugging which XCode 8.x contains. There is a WWDC talk which includes it (along with other debugging elements) that is located here.
You can also search "memory graph debugger xcode" in your favorite search engine to learn more (I could include links but they are not guaranteed to be around).
I just start using Appcelerator and I seek some information about it and I have read that Appcelerator has a huge problem with memory management and memory leaks. I would like to know if that is true before I decide to use it. Does Appcelerator have problems to manage memory?
In one word: No
It's up to you. If you code clean and reusable, Appcelerator will not have memory leaks.
I also ran into memory problems. And in 95% it was my fault.
Appcelerator had memory leaks in the past. But since SDK 4.0 the most things are done and the SDK only gets better.
Give it a try and build the example apps to have a feeling how fast Appcelerator can be.
As a titanium developer for quite a while now I haven't seen any memory problems that are caused by titanium (except for some minor issues on Android with the older versions). Available memory on mobile devices can be relatively small and with Titanium, although they work hard on reducing this, there is always an extra framework layer consuming extra memory. It's just a matter of keeping this into account and writing clean javascript with as few unneeded variables as possible left open.
There is a great guide about Titanium, Memory management and Javascript garbage collection on the Appcelerator Documentation website with good tips on how to monitor with Xcode as well.
There is also a must read article about this topic on TiDev which you should also definitely check out!
I haven't found an issue with the Titanium SDK leaking memory. Any issues have been my fault, not cleaning up a reference, not nulling, or forgetting to remove an event listener. The guides mentioned above are an excellent resource. As stated clean JavaScript keeps the maximum memory released.
I am trying to understand the inner workings of XCode's Instruments. On MacOS, it can rely on DTrace to gather all kinds of profiling data. On iOS, it is also capable of lots of things, but I have read repeatedly that DTrace has not been ported to iOS.
So how does that work?
The Apple documentation on DTrace isn't telling me much about the inner workings here. I have noticed, however, that when profiling my own App from XCode using Instruments, XCode seems to build it differently. Could that mean it links some standalone DTrace providers with my code?
Thanks in advance!
/e: I would bounty this question with my ENTIRE 6 REPUTATION POINTS if only i could...
For iOS apps running inside the Simulator, obviously the Simulator is a Mac OS X program, so it can use DTrace to monitor everything the Simulator does.
For iOS apps running on an iPhone, I agree the documentation provides little insight into what's happening. It's probably either loading monitoring code into the target process on iOS (either by adding the code at compile time or by linking it in at runtime) or there is an "traditional debugger" running on iOS against the target process to implement the tracing. Those are pretty much the only options if there is no kernel-level support for using DTrace.
I've never used Instruments, but the main thing that jumps out at me is that they're able to collect seemingly-OS-level statistics about I/O, which would not normally be measurable without DTrace. I'm not sure because I haven't used it, but it's possible these statistics are only tracking I/O from easy-to-detect entrypoints (ie I/O-related syscalls from the specific target process), or that there are other iOS-specific statistic sources which are published by the OS. For instance, many system statistics can be gotten from Mac OS X by calling sysctl. Depending on what statistics are actually being collected, Instruments could just be using simple counters like these to do most of the work.
If you're really determined to find the answer, it would be a fun DTrace challenge to figure this problem out by DTracing Instruments itself. Good luck :-)
I've finally reached the end of app creation.
I know that Instruments and Shark can be used to test for memory leaks and other such "bad stuff" in your apps. Unfortunately I can't find any good tutorials on how to use these tools.
Especially for Shark, how should I go about using these tools?
Additionally, are there any other similar tools that may be more powerful or easy to use? Thanks you!
One way to find memory leaks and other problems is to use static analysis. If you're using Xcode, there's an integrated tool that's located in Product->Analyze.
Shark is no longer really used, use the Time Profiler instrument instead.
Currently your best bet is reading through the Apple documentation on Instruments.
I am looking for some advice on memory usage on mobile devices, BlackBerry in particular. Using some profiling tools we have calculated a working set size in RAM of 525kb. Problem is we don't really know whether this is acceptable or too high ?
Can anyone give any insight into their own experience with memory usage on BlackBerry? What sort of number should we be aiming for?
I am also wondering what sort of things we should be looking out for in particular to reduce memory usage.
512KB is perfectly acceptable on the current generation of BlackBerrys devices. You can take a look at JBenchmark to see the exact JVM heap you can expect for each model, but none of the current devices out there go below 20MB of heap. Most are much larger than that.
On JBenchmark you can choose the device you are interested from a drop down on the right side of the page. Then, navigate to the JVM Tab for the device.
When it comes to reducing memory usage I wouldn't worry about the total bytes used for this application if you are truly inline with 525K, just about how often allocation/reallocation is required. Try to pool/reuse objects as much as possible, avoiding any unneeded allocation. For instance, use the StringBuffer class to concatenate strings instead of operators as multiple String objects will be created for each concatenation using the operator, where a StringBuffer will just put the characters in an array and only expand when needed. Google is a good way to find more tips.
Finally, relying on profiling tools, which the BlackBerry JDE has, is a very important part of understanding exactly how you can optimize heap memory usage.
If I'm not mistaken, Blackberry apps are written in Java... which is a managed environment, which means really the only surefire way to use less memory is to create fewer objects. There's not a whole lot you can do about your working set, I think, since it's managed by the runtime (which is actually probably the point of using Java on devices like this).