High CPU Usage when run as Debug vs as Release (Instruments run as Release). How to Debug? - ios

I've been having what I would think as performance issue on my app when running on old hardware (iPad mini 2 which is close to 7 years old). It's unfortunately seems like sporadic whereby 2/10 times it runs OK and the rest, CPU Usage creeps upwards of 90% as time goes by.
The App is doing some intensive(?). drawRect stuffs where I use bezierpath to draw a live HeartRate (among others) chart. Using Instruments does not really show me where the possible bottleneck is occurring. (TBH, I'm not very good at reading the output tho)
(for this image, I used 'invert call tree', 'hide system libraries'
I tried putting in some time profiling of my own
let start = CFAbsoluteTimeGetCurrent()
let end = CFAbsoluteTimeGetCurrent() - start
print("drawRect END:\(Date()) - total Secs:\(end)")
and while it's slower than my iPhone 7, I think it's still acceptable.
drawRect END:2021-01-16 00:39:26 +0000 - total Secs:0.002599000930786133
drawRect END:2021-01-16 00:39:27 +0000 - total Secs:0.001813054084777832
drawRect END:2021-01-16 00:39:28 +0000 - total Secs:0.0019180774688720703
drawRect END:2021-01-16 00:39:29 +0000 - total Secs:0.0016759634017944336
In the end, I found this post --> https://developer.apple.com/forums/thread/19936 and when I started the run as "release" then the high CPU Usage basically went away.
Question:
During normal app development, I agree that running as Debug would be beneficial, but what are the actual benefit? How is the Debug config different? (Some reading material / Links would be good) TQ
If instruments are running as "release" config, then how does one actually be able to figure out what's happening under the hood? Like in my case, I had no idea Instruments is running as "release" and normal run (Cmd-R) is running as "Debug". This is a big mismatch and obviously threw me off.
So.. Do I have an issue or do I not? It's highly likely that I do, but I, for the life of me, can't seems to figure out why.
The iPad Mini2 is definitely old and slow. I downloaded some CPU/System monitor app from the store and just running it I am seeing 40% CPU usage already (!!) Is there a way to collect CPU usage data within the app? like in a Print statement.
Thanks.

The benefit of the Debug configuration is that it lets you debug your app. The Debug configuration lets you see things like the values of variables. If you tried to debug your app with the Release configuration, you would see memory addresses instead of variable names. The Debug build configuration sacrifices speed for the ability to debug. The Release build configuration sacrifices debugging for speed.
If you want to see the problem you're having when running in the Debug configuration, edit your project scheme and tell Xcode to use the Debug configuration for profiling. Then Instruments can help you find where the slow spots are in the code in the Debug configuration.
Focus on time profiling for the Release build configuration, the configuration the people using your app will see.
Take a look at the os and OSLog framework references in Apple's documentation, which you can read in Xcode by choosing Help > Developer Documentation. The os and OSLog frameworks are in the System section. Those frameworks are how you collect profiling data from your code.
For a more detailed explanation of the Time Profiler instrument, read the following article:
Finding the Slow Spots in Your Code with the Time Profiler Instrument

Related

Time profiler related error in Xcode profiler: Instruments

While profiling an app (which has metal codes for gpu acceleration) Time Profiler Instrument gives the error as in the screenshot:
It says, No configuration information received.
I want to know what kind of configuration is missing and how to configure it. I have also observed that other instruments: Allocations, Leaks, VM Tracker has no issues.
I would make sure OSX, XCode and the device's iOS are all fully up to date and power cycle everything. If that doesn't fix it, I'd temporarily modify the app's deployment target to the highest possible option.
If that doesn't fix it check to see if it happens using the metal demo (XCode->File->New->Project->iOS Game Metal) then look to file a bug with Apple: https://feedbackassistant.apple.com/

Difference in iOS allocation between XCode and instruments [duplicate]

I'm using XCode 7.0 with iOS 9.0 SDK & ARC, all profiling/testing done on an iPhone 5S with iOS 9. EDIT: for all screenshots, it was a single run: I ran a debug build straight from xcode, and then manually attached Instruments to it. So the screenshots are all from the exact same single test run. This memory growth (per xcode view) is 100% reproducible.
My app downloads ZIP files, unpacks them, and adds them to the camera roll. I've made sure to profile and catch memory leaks (ie. missing CGContextRelease) as well as using #autoreleasepool etc
During unzipping, in xcode I see the memory usage shooting up fast, never-ending until the unzipping finishes, and I cannot explain this because there are no objects in Instruments that I can see being held onto. The memory is never released (per xcode's memory view). At the end of my test run I see 236MB used, with no memory warnings during unzipping. If I use Instruments' allocation tool, I see 50.2MB of heap and anonymous VM used. That's a huge difference!
The first thing I did was assume that [UIImage imageNamed:was to blame (caching etc) because I have quite a few animated UIImageViews, so I spent time removing all imageNamed from my code, and using imageWithContentsOfFile instead. That didn't help at all. I add the unzipped images to the camera roll with iOS 8 Photo framework like this: [PHAssetChangeRequest creationRequestForAssetFromImageAtFileURL:[NSURL fileURLWithPath:filePath]]
I've spent considerable time pouring through Instruments and web articles but to no avail. Can anyone answer these questions?
Why the discrepancy between xcode memory usage & Instruments -- is this normal?
I assume that these numbers are too high for releasing such an app, and I have to improve this before I upload to app store, right?
Looking at the screenshots below can you make any suggestions where I could start looking for the problem(s)?
Thank you very much in advance for your help. Of course i'll post any source-code that would help, i'm just not sure where to begin...
XCODE MEMORY USAGE 236 MB
INSTRUMENTS
The most common cause of this is your configuration. By default when you run in Xcode, you build in Debug mode. When you profile in Instruments, by default, it builds Release. You can modify your Run and Profile configurations in your scheme to change this.

Why the huge difference between XCode & instruments memory usage, and is it ok?

I'm using XCode 7.0 with iOS 9.0 SDK & ARC, all profiling/testing done on an iPhone 5S with iOS 9. EDIT: for all screenshots, it was a single run: I ran a debug build straight from xcode, and then manually attached Instruments to it. So the screenshots are all from the exact same single test run. This memory growth (per xcode view) is 100% reproducible.
My app downloads ZIP files, unpacks them, and adds them to the camera roll. I've made sure to profile and catch memory leaks (ie. missing CGContextRelease) as well as using #autoreleasepool etc
During unzipping, in xcode I see the memory usage shooting up fast, never-ending until the unzipping finishes, and I cannot explain this because there are no objects in Instruments that I can see being held onto. The memory is never released (per xcode's memory view). At the end of my test run I see 236MB used, with no memory warnings during unzipping. If I use Instruments' allocation tool, I see 50.2MB of heap and anonymous VM used. That's a huge difference!
The first thing I did was assume that [UIImage imageNamed:was to blame (caching etc) because I have quite a few animated UIImageViews, so I spent time removing all imageNamed from my code, and using imageWithContentsOfFile instead. That didn't help at all. I add the unzipped images to the camera roll with iOS 8 Photo framework like this: [PHAssetChangeRequest creationRequestForAssetFromImageAtFileURL:[NSURL fileURLWithPath:filePath]]
I've spent considerable time pouring through Instruments and web articles but to no avail. Can anyone answer these questions?
Why the discrepancy between xcode memory usage & Instruments -- is this normal?
I assume that these numbers are too high for releasing such an app, and I have to improve this before I upload to app store, right?
Looking at the screenshots below can you make any suggestions where I could start looking for the problem(s)?
Thank you very much in advance for your help. Of course i'll post any source-code that would help, i'm just not sure where to begin...
XCODE MEMORY USAGE 236 MB
INSTRUMENTS
The most common cause of this is your configuration. By default when you run in Xcode, you build in Debug mode. When you profile in Instruments, by default, it builds Release. You can modify your Run and Profile configurations in your scheme to change this.

Swift app only performing reasonably when built for Xcode's Time Profiler?

I'm working on an app that processes large float arrays, and I was extremely disappointed to find that Swift is apparently a good 10x slower than Python when running on my iPhone 5. I guess that can't be true, but I would have thought it true had I not tested the app in the Time Profiler and realized that it's probably not my algorithm or Swift's implementation causing the issues.
When the app is built for the profiler, it performs nicely: It does the processing in an imperceptibly small amount of time, as it should. But normally, if I hit the run button (play symbol) in Xcode to build and run, even with the compiler set to be Fastest, it takes almost 20 seconds to complete. (Code remains unchanged between builds.) It's ridiculously slow.
It's reasonably fast when I build and run in a simulator on my MacBook Pro, but even then it's slower than it is when built and run through the Time Profiler on my little iPhone 5.
The performance difference between builds is also present when I place the following test code in the application() function in AppDelegate, so I don't think it's a GUI/threading issue or anything. And the same test code runs quickly when implemented in Objective-C (in a separate app on my device) and Python on my Mac.
var nums: [Float] = []
for var i = 0; i < 250000; i++ {
nums.append(Float(i) * 0.001)
}
(This takes around 20 seconds unless run through the Time Profiler.)
Have any of you experienced anything like this before? I'd be immensely happy if you could help me figure this out.
You were building the app in Debug mode instead of Release mode. Debug mode is much easier to debug, but release mode generates faster code.
When building for Debug mode, the compiler inserts special debug symbols that help the debugger. I once tried to debug an app in Release mode and the debugger couldn't even find my variables. Release mode not only doesn't include those symbols, but it also optimizes your app, generating a binary that is much smaller and faster.
Here's how to switch between Debug and Release mode:
Click on your scheme in the top-left corner of Xcode.
Select "Edit Scheme..."
Click on the "Build Configuration" dropdown.
Change the build configuration to Release.
Rebuild your project.
(I am not providing an image here because I assume you know how to rebuild your project.)

Apple Instruments - Counters - Source unavailable

I've been running into a problem with Apple Instruments (4.6, Xcode 4.6.2 on 10.8.3).
Normally when using the Time Profiler, I can look at my source and see the hotspots without any problems (same project).
This time I've been trying to use the "Counters" Template to sample my CPUs Performance Counter Events. It samples the events as it should and I also have the same time based profiling information as well, however when I try to step into my code to look at the hot spots, like I can do for the "Time Profiler", all I get is "Unavailable" where I used to have the source. No Assembly either.
The Project is built as:
Release build
Debugging information is on and not stripped
DWARF + dsym is used to store the profiling data.
As I said, its the same configuration that works for the time profiler.
I already tried to (pretty much all that's stated in here: Xcode 4 Instruments doesn't show source lines , except for doing -O0, debug performance is not of interest to me)
recompile
relocate the dysm file using "File -> Re-Symbolicate"
As soon as I plainly close Instruments, start another Profile from Xcode and choose the Time Profiler, it works, if I go back to the Performance Counters, it stops.
Is this the default behaviour? Should it be like this? Has anybody already managed to get it working, in the current Instruments version? Otherwise it might be worth to file a bug with Apple.
Thanks a lot!
Try the Xcode 5.1 beta4. For me its fixed there: Counter works now.
The seed notes mentions some details what they did. Don't know if its under NDA.

Resources