I have developed an app using Ionic 3 framework. I would like to measure the CPU and memory usage of my app. What is the best practice to do so?
You must not use AndroidStudio and XCode to measure the memory usage of the Ionic app.
Why? Here is the comment from Ionic team member
Unfortunately we have not been able to reproduce this issue on our
end. Would you mind checking your app on your device with safari dev
tools instead of the memory tool in xcode? The reason I recommend this
is because the xcode memory tools can be misleading in the fact that
it's not actually measuring memory usage of the javascript heap of the
app, instead, it is reading the memory used by the kernel / OS itself.
So based off the same concept I described here, the OS will not free
up memory used by the JS virtual machine if it 1. thinks the action
that used that memory is going to happen often and 2. thinks that it
has plenty of memory to spare. So, while the JS heap memory will be
shrinking every time the JS engine runs garbage collection, that does
not mean that the memory that iOS has allocated to the browser will
shrink, and, if iOS did start freeing up memory when it has plenty of
memory available you would actually see performance issues. Also, it's
important to remember that high memory usage does not === a memory
leak and in fact operating systems are built to take the most
advantage of the resources (in this case ram) available to it,
especially on mobile devices.
Tools:
Safari dev tools
Chrome dev tools
Related
So I have got a Xamarin.Android application and a Sencha application.
Both are exactly the same application just developed on two different frameworks.
Now the Sencha application consumes around 60mb - 100mb RAM and the Xamarin app, on the other hand, takes 100mb - 250mb of RAM.
I understand that due to Mono.Android runtime the Xamarin App is supposed to take much memory, so I created a blank app on Xamarin.Android and it takes approx 90mb - 100mb memory.
So my question is how can I reduce the memory usage by the Xamarin app? Or is it normal to have this kind of RAM usage on a Xamarin Application?
Is there any reference point which I can consider in order to benchmark my application's RAM usage?
What is the general RAM usage by Enterprise applications, developed on Xamarin?
Please note that all these RAM usage statistics are collected using the Android Studio Profiler.
To reduce Xamarin android application memory usage, do followings:
1- Use liker (Link All is better) to reduce loaded assemblies into memory.
2- Use AOT/LLVM to remove JIT overhead including memory usage.
I've got a C++ program that is notably slower on OSX 10.8.2 than on Linux. Profiling shows that the reason is that calls to free (that result from STL operations, FWIW), are much slower on OSX, because they go and call madvise, and real time gets consumed in there.
Is there any way to modulate this behavior of OS/X?
Well, yes!
I had horrible performance issues with malloc/free in Linux and started looking for a replacement.
Two options came to mind tbbmalloc (part of Intel TBB which is free BTW) and Google malloc.
After extensive testing it wasn't clear which was faster (of the two) but both were significantly faster than LIBC's implementation.
I went with tbbmalloc since it was working smoother, google malloc had a bug that caused virtual memory to be very large (reserved but not committed) which was very bad for my app (IT daemons would kill it).
The good:
Much better performance than libc's malloc. Was 3x-300x in STL heavy app.
Simple integration. No code change. Add/change 1 line the executable's makefile. No change to SOs.
The bad:
Mem checkers will not with replacements. for memchk/valgrind/etc. revert to the original malloc.
App would take 10-30% more memory.
The app I developed was a CAD application that used 10s of GBs, building and destroying 10s of millions various structures (lots of STL maps, vectors, hash_maps).
How to do this:
In the linker command, add -ltbbmalloc and make sure the library is in the lib search path (-L flag).
Are there any tools that would allow me to monitor memory usage and leaks? For example, I want to track memory usage when releasing objects manually vs automatically with ARC enabled.
It's called instruments, you can acces it from Product -> Profile -> Leaks in xcode
Instruments is probably the easiest to use and does a pretty good job. It comes with Xcode and you can run it directly from Xcode when you launch your application.
Instruments is quite good at this, but still I find myself using the leaks and heap utilities quite often.
I am using Xcode 4.2 on a relatively large project (a few ten thousand lines of code) and it is horribly slow. Editing is ok, but whenever I try to compile the project (in Xcode, or with xcodebuild on the command line), my machine (quad core i7 MacBook Pro, 4 GB RAM) crawls to a halt. I have noticed that directly after starting xcodebuild, it spawns more than 8 clang processes, without the "real" compile processes starting. No xcodebuild output is so far seen on stout. I've tried reducing the number of parallel build processes, but still lots of clang processes are launched at the beginning. The project uses 6 or 7 direct dependent external projects and has maybe 120 source files. Under Xcode 3.2 the project used to be compiled very quickly. What's happening? And how can I make Xcode fast again?
Most of us have three primary options:
Revert to Xcode 3 for daily development.
Throw more hardware at it.
Change your projects' structures and apply large scale development tricks (even though 20-30 KSLOC is not large).
The easiest solution is revert to Xc3. Yes, Xc4 requires a lot more than Xc3; memory, CPU, and disk space and I/O. You will have to determine where your biggest problems are to reduce the amount it affects you.
I recently bought a new MBP with twice the physical cores and twice the physical memory, upgraded to Lion and upgraded Xc4 at the same time. The compilation times did improve, but much of the rest is actually slower, and far more resource hungry. That's not at all what one would expect from an IDE which also disallows multiple open projects and also uses a unified workspace view.
The move to Lion + Xc4 more than doubled my hardware demands in all of the following categories:
Memory
4GB is now too little for most nontrivial projects using Xc4 and Lion. You can still reduce this. I have 8GB and 10GB on my main 2 machines, Xc4 consumes it all quite easily (but my projects are more complex than yours, unless you write reeaeaaaally long lines). Anyways, You can reduce this problem by:
Buying more memory.
Disable indexing if you are building out huge projects in Xcode. This can halve Xcode's memory consumption.
Running Xcode in 32 bit. This is not an option for everyone, because it will exceed 4 GB in larger projects.
Reduce the number of build processes (again).
Restarting Xcode often (It doesn't do a very good job cleaning up after itself).
Use clang as your compiler. Clang instances in general use less memory than Apple's GCC 4.2.
Offload dependent targets which do not change often. Example: You will not need to rebuild third party libraries daily in most cases.
CPU
Xcode 4 uses a new (more accurate) completion parser.
Pare down your include dependency graphs, and dependencies. This is quite easy to with Obj-C, since every Obj-C instance is a pointer. Example: remove loosely dependent framework includes from your headers.
Separate your dependencies and modules properly. Develop libraries, but try to make them fairly small and be aware of the dependencies they will add. Example: I lead a project where a dev added a small feature (less than 1% of the app), but due to the number of dependencies it required (e.g. Three20 and then a few more), the binary size of the final executable doubled (and the build times went up, and the parser had a lot more work to do). Most of this was not needed for the feature - they just could not be stripped because they were objc symbols.
Reduce translation counts, if possible.
Optimize how you use prefix headers. You can share them, and you can create them for no good reason. This benefits the compiler more than the IDE.
Minimize memory usage. GC work (including all NSObject allocs) consumes over 1/3 of the CPU usage in larger projects, but it still spends a lot of time collecting when its heap is huge.
Use external text editors and VC clients. Pretty obvious because Xc4 displays the SBBOD rather often in large projects.
Minimize language complexity. In order of complexity: C, ObjC, C++, ObjC++. The more complex the translations, the longer it will take to parse and compile your sources, especially when your dependencies are high. If you can easily set up language barriers in your dependencies, do so.
You can disable code sense indexing via defaults (also reduces memory demands).
Hard Disk
This can be a speed/size balance.
Buy a faster one (e.g. SSD).
Cleanup and minimize your header dependencies.
Use a RAM Disk, such as Make RAM Disk.
Buy more memory. With the amount Xc4 consumes, it ends up swapping out to disk often in large projects.
Optimize your builds to use pch files appropriately. This is not always the obvious direction: I have not used them for several years in large projects.
Clear out the temp files Xcode and Instruments leave behind, they can be huge. In some cases, you can save them in customized locations. If they do consume tens of GB and your build dir is the same as your boot dir, then you will make your disk work a lot less by cleaning them up regularly.
Builds
In Xc4, xcodebuild parallel to Xcode now doubles the work (separate build dirs by default). In Xc3, the default was to build to the same destination. Verify your settings - Xcode will do a ton of redundant building, if you allow it (e.g. one target per workspace/config, rather than Xc3's flat build model).
Or just fill a drawer with quad core MacMinis and use that as a dedicated or distributed builder.
File Bugs
(self explanatory)
One more possible solution that in some cases might help speed up Xcode 4: In my case, the main problem seems to have been that accidentally four files from my build/ folder had been checked in with my git repository. During compilation Xcode notices that the build folder changed, and triggers git. Since the build folder contains thousands of files in my case, the performance went down. Removing the build/ folder completely from git (shouldn't have been checked in anyway) reduced the compilation times and system load massively. Performance is still slower than with Xcode 3, but much better than before.
You can switch on Distributed Building in XCode Preferences, and find some friendly person who will help you build your app by forming compilation machines cluster with you.
The funny thing is that even he is off, your compiler still uses different algorithm/mechanism to build you app in a blazing speed if compared to the problems before ;)
So, that means that they at Apple have forgotten about lonely programmers who don't work in teams and therefore lonely compilation scenario is purely tested in versions 4.0 - 4.2
Quick Note Regarding 'Throw more hardware at it' approach..
SUMMARY: I experienced a SMALL speed increase from making a SIGNIFICANT hardware upgrade
Test: Build/Run the exact same project on cloned macbooks (where the only difference should be their hardware)
Old Macbook Air (1.86GHZ Core 2 Duo ONLY 2GB RAM)
vs
Brand New Macbook Pro (2.3GHZ Core i7 8GB RAM)
BUILDING ON IPHONE 3GS
Macbook Air 1:00 - 1:15
Macbook Pro ~1:00
=> 0 to 0:15 of speed increase
BUILDING ON IPHONE 4S
Macbook Pro ~0:35
Macbook Air ~0:50
=> ~15 seconds of speed increase
**Partially tested: There DOES apear to a significant difference between build times for the SIMULATOR between the 2 machines
Another culprit for slowness is plugins. The Subversions plugin was absolutely killing my Xcode performance. I followed the instructions in this SO post to disable it. WHEW!
I'm looking for a tool which can monitor a running application (Win32/COM) for a long duration (1-3 days) and detect memory leaks if any. Any suggestions?
It is a .NET Windows application calling lots of unmanaged code.
You can try Memory Validator
iJeeves, the combination of BoundsChecker and .NET memory profiling should help you with your memory analysis. DevPartner Studio 10.5 ships February 4, 2011 with 64-bit application support. Depending on your application raw memory footprint, you may run x86 build configurations with the error dectection memory tracking analysis as long as you keep below the 2gb overall process virtual address limit, 3gb if you link the exe with LARGE_ADDRESS_AWARE and run on an x64 OS with extra RAM. The x64 build configuration will let you go up as high as your system RAM allows, at least until you start paging and performance grinds to a standstill. You can run BC error dection for your native code under the .NET process, but object leaks or held references in managed code require a second pass using the .NET memory profiler. We do not yet have a single pass analysis that can handle the mixed C++ and .NET code with full mixed stack traces but we can handle managed code above the line, any PInvokes that cross the line, and all native activity below the line in two passes. Shameless plug: I work on the DevPartner team. The links above pointing to microfocus.com acurately resolve to DevPartner pages. Look for DPS 10.5 when it ships and pull down the eval to see if it meets your needs.
AQTime is nice, I used it several times and it helped me with some tricky bugs.
I used to use Bounds Checker but nowadays I either use the Micrsoft inbuilt CRT library or build my own.
If your looking for a pay$'s tool then DevPartner is well worth using. It has memory leak detection for managed, and unmanaged code.
Application Verifier is free and from Microsoft. It detects memory leaks, double frees, overwrites and many other things. I use it all the time and it has helped me track down some nasty issues.