When launching my app i get the launch screen for about 2-3 seconds and only then my first UIViewController appears.
And some times my ViewDIdAppear is being called before the UIViewController is actually appearing.
I have a pretty big storyboard (15 screens).
I have some flags that i check from UserDefaults (user is logged-in ...), and i initialize crashlytics and GCM.
So the flags and the initializing doesn't seem to be the problem.
I checked system time differences and it seems to be OK.
Any ideas for debugging the slow launch?
In Xcode: Product -> Profile
Choose the "Time Profiler"
Running this tool will give you time spent in every method in your program, and it'll give you that information in a hierarchical structure. This should give you an idea where most of the time is spent. Keep in mind that the instrumentation adds extra overhead, so the absolute time value may not be correct, but the proportion of time spend in each method should what you need to debug this issue.
Here is a decent looking tutorial (albeit on an older version of Xcode) showing how to use this tool.
The time profiler will not help you if the slowness is from the initialization time. During that time none of your code is running yet, so the time profile won't be logging anything.
You can have xcode print out stattics on how long it take to launch by going to 'edit scheme' -> run -> environment variables add add DYLD_PRINT_STATISTICS with a value of 1. Ideally you want your launch time to be less than 400ms which is about the length of the opening animation. I was able to cut my launch time in half by removing use_frameworks! from cocoapods. And I was able to to cut it in half again by removing unused external libraries.
There is a great apple lecture on the topic here:
https://developer.apple.com/videos/play/wwdc2016/406/
Related
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
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.)
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.
I have a huge synchronization process in which I download and unzip 400-500 XML files and then parse it. With this data Im going to create a lot of core data objects over the RestKit API. At the beginning, I had a memory warning with live bytes of 450mb+ because I did not using autorelease pools and only tried to save core data on the end.
I fixed that, saving now frequently to core data and using #autoreleasepool blocks. When im running my app now with instruments, I can see how the live bytes only being 20mb-30mb, always releasing memory and never going to size up. The process just works. But when I start the app without instruments, after a view files I get a Memory Warning. Later on the app crashs.
What is the differene between running the app with and without the instruments tool? Why does it end in different results?
I'm adding this answer because I'm so happy that I came across this page.
What #borrrden suggested is partially true. You can configure which Build settings it will use when you profile. To configure this, goto Xcode and open the Edit Scheme dialog and select in the left menu Profile XXX.app. You will see you can choose a Build Configuration (either Debug or Release).
What #hooleyhoop commented was more crucial to find the solution. Even if your Profile Build Configuration is set to Debug, there is still a difference between Profiling and a default Run from within Xcode. You can specify Diagnostics in the Run section. Right there, there is an option called Enable Zombie Objects under Memory Management. Make sure that this option is unchecked.
These diagnostic Run settings are not used while profiling. That is the explanation for the behavior you are experiencing. There isn't a Diagnostics tab on the Profile section as well.
The result is that my game (Gump) crashed after 5 minutes of doing nothing in the main menu with Zombie Objects enabled. Once I disabled Zombie Objects, my game runs as far as I know for an infinite amount of time. After 45 minutes, still no Memory Warnings.
I've got an iOS app that links to 15 Apple frameworks (including the ~3 basic ones every app uses). I've noticed that my app's load time, and time restoring from the background, is pretty high, though the executable is only 600kb. Could all these frameworks be the cause of the load time issue? And is it possible to, say, lazily-load frameworks as needed?
Yes dynamically linked frameworks do affect load time, you can see this in instruments using the time profiler. You should see dyload running as your app launches and it will take time to load in each framework.
Even worse if have static code in something like +initialize this will run at load time too, further slowing your app.