I need to measure the performance of a couple of lines of code in my iPhone app. I have a macro that does the job well, but it writes the output to NSLog afterwards (with a delay to make sure that NSLog does not affect the actual performance measurement), so I always have to attach the debugger to the device to get the results.
Now I am wondering if and how the debugger affects performance of the App, eg. I imagine it doesn't affect disk reading/writing commands but probably eats up some CPU time. Are there any docs on this topic? What tools are out there to get performance measurements of apps without the effect of the debugger?
In addition to David's answer, I would say, why don't you try it?
In Xcode 4, go to Product > Edit Scheme... > Run action > Info tab and choose Debugger "None". This way the debugger is disabled and you can test the way you like.
From what I have experienced, other than a jump in RAM there's no difference at all.
However, if you debug using NSZombieEnabled, you can experience some lags.
Related
I don't see any way to start/stop profiling in Instruments from code, which kinda kills its usefulness for me in a large number of situations.. Am I missing something? Does anyone know of a way to do this?
The fallback approach is to grab performance data on my own, without Instruments. Has anyone tried to do this before? By "performance data" I mean counts of events like cache misses, fills, missed branches, etc.
Thanks!
Update:
I looked into operating the performance monitor hw directly from code, but, unsurprisingly, it appears to be a no-go. USEREN, the "user enable register" controls access to perfmon registers but is not enabled. It might be possible to run privileged or enable user access with a jailbroken phone, but that's a lot of work for some basic profiling.. ugh.
I need to debug a certain ViewController I have and I can't seem to pinpoint exactly what is causing my lag time for the view to show.
IS there any debugger tool in Xcode that will show me how long my methods are taking to run so i can at least find the right place to start?
Instruments has a profiler built into it ever since iOS 4.0 (before which you used a stand-alone profiler tool called Shark).
Here's a quick little tutorial that will get you started: http://blancer.com/tutorials/flex/78335/apple-profiling-tools-shark-is-out-instruments-is-in/
If you don't know about Instruments, you should. It's how you know what's really going on inside your code while it runs.
Apart from Time Profiler as suggested by Dan you can also use Sampler instrument which generally stops a program at prescribed intervals and records the stack trace information for each of the program’s threads. You can use this information to determine where execution time is being spent in your program and improve your code to reduce running time.
The main difference between sampler & Time profiler :
Sampler instrument operates upon a single process but Time Profiler operates upon a single/All processes.
Hey all, I have a problem and I'd like some advice.
I'm working on a document viewer that's composed of the following major parts:
zip library which unpacks the document container (minizip)
xml library which parses the document (libxml2)
UI code which renders the document on screen
Nothing too complicated or fancy.
On the emulator, everything works beautifully; the viewer performs as expected. I've ran it through Instruments and there are no leaks. ObjectAlloc reports about 5.5 megs allocated over the lifetime of the viewer (that's repeatedly opening my test document over and over).
Unfortunately on the device (iphone 3G, iOS 3.1.2) things aren't as clear. Fairly frequently, repeated opening of the test file causes an out of memory error and the file will fail to open. Initial file opening always works. Even though emulator testing highlighted no leaks and the overall memory footprint was modest, I'm forced to conclude that there IS indeed a leak on the iphone (because why would repeated opening cause out of memory error).
I've attempted to run instruments on the device, but the app stalls (?!) half way through the run, so I actually had no success running Leaks.
I believe that there's a significant leak somewhere that only shows up on the device. So, I'm left with a two options (in no particular order):
Refactor my code in such a way as to avoid using zip library. That would eliminate a potential source of leaks. Time consuming and inconclusive.
Reformat and reinstall everything on my phone (maybe there's something that's causing a problem there). Pretty much as above, time consuming and sucks losing my phone data. Maybe it'll let me run Leaks though.
As you can see, I'm reaching here. Is there anything obvious that I'm missing?
Thanks in advance guys.
Maybe, you should try to run not Leaks, but Allocations Instrument on your device, and to search leaks with it (manually)?
+ (maybe this sounds stupid) Remove app from the device and repeat Clean-Build-Run with Leaks (why not?).
About manual leaks search.
Just start the Allocations Instrument and, while using your app, do every action for several times (for example - press button twice or more; navigate to some panel and back for several times - and so on). Memory should increase significantly only once or increase on action start and decrease on action end (of course, some divergences are possible, but they should be reflected with small amounts of memory). You will see it on graph.
Also make heaps (in Instruments' left panel while Allocations Instrument is selected there is a button for this) - they will help you to detect "still alive" objects that were considered as destroyed (there will be a lot of objects, but the first and easiest step is to check objects of your own classes).
I have a critical method in an Objective-C application that I need to optimize as much as possible. I first need to take some easy benchmarks on this one single method so I can compare my progress as I optimize.
What is the easiest way to track the execution time of a given method in, say, milliseconds, and print that to console.
CFAbsoluteTimeGetCurrent() (about 6 microseconds) or mach_absolute_time() from mach/mach_time.h (somewhat faster, but you need to call mach_timebase_info() and do some conversions). You can then print to stdout or use NSLog; note that NSLog takes ages (50 ms?) so you want to do it after taking the measurements. stdout is a bit faster, I think, but doesn't go to syslog (i.e. the Xcode Organizer/iPhone Configuration Utility console).
One thing the others haven't mentioned... when you're performance-checking with Instruments or Shark, be running your app on a device rather than the simulator. The device much slower than the simulator for many things, but sometimes actually faster for some things which it's hardware accelerated for but the simulator isn't, so checking on the device is the only way to get an accurate picture.
Also, be aware that NSLogs can slow it down lots.
There are quite a few ways to instrument your code, but running it through Instruments and/or Shark should give you enough information to see where your code is slow. But remember premature optimization is the root of all evil.
Instruments
To be clear, this is for a normal iPhone application, and not a game.
I've read around the web a few times some developers mentioning that they were working hard to improve/reduce the startup time of their applications, but never with any good background information on how to do so.
So the question is simple: how can you reduce the startup of iPhone applications?
Same as any other performance issue: Use Shark and/or Instruments to identify bottlenecks in your code, and then focus on how you can speed things up there. Each tool will give you a picture of how much time was spent in what parts of your code, so the general scheme would be to run the tool while you start the app and then pore over the data to see where the performance hits occur.
At app startup time, the most likely candidates for improvement will be deferring data loading until later on when it's actually needed, variously described as "on demand" or "lazy" loading. Essentially, don't load any data at app startup unless it's actually needed right away when the app loads. In practice, lots of stuff that may be needed at some point doesn't have to be immediately available when the app starts. For example, if you have a database of N records but only one is visible at a time, don't load all N into memory at app startup time. Load whatever the current record is and then load the others when you actually need them.
James Thomson did a nice blog post documenting his efforts to make PCalc launch faster.
Of particular interest is his use of image with screenshot from last app run, to pull the same trick Default.png does, while loading rest of the app.