I was wondering if there was a performance difference if you launch an app on your iPhone from Xcode vs starting it up from the phone itself. When you launch it from Xcode it seems to be on a debug "lite" mode in the sense that you are getting data to the console.
Are there any performance differences when you don't launch from Xcode ?
There are performance differences. You wouldn't be able to put a general number on how big they are, because they depend on a number of factors. The differences can go from not noticeable to significantly slowing down even a fairly simple application.
First you have three different operating modes:
A release build that is installed to the device directly
This will enable things such as compiler optimizations. For exact settings have a look at your project file.
A debug build run with a debugger attached (e.g. by launching from Xcode)
On top of your application missing compiler optimizations because of being built with the debug configuration, the debugger can be an additional performance drain.
From personal experience I know that having a lot of breakpoints (especially symbolic ones) or watchpoints, can make things noticably slower. You may experience similar problems if you are doing intensive logging.
In some projects debug code is also compiled to work slightly differently than in production. For example if using a logging framework such as CocoaLumberjack, you would set a more verbose log level, which can again be more processing work.
A debug build run without a debugger attached (e.g. by installing through Xcode and launching separately)
You will not have any compiler optimizations and still work on Debug configuration logic, but your application isn't additionally slowed down by the debugger
Actually there could be a lot of difference between debug and release codes.
By default debug build don't use optimizations but add debug symbols to the binaries created. These two can have dramatic effect on the app performance, size and some.
You can go and look at the project settings file to understand what exactly are the differences.
But again to your question, there could be performance changes between debug and release.
Related
I create a hybrid app using apache cordova and I want to run some test using APPIUM (pytest).
Can I use the app build or the debug build for testing?
I really don't know what is the effect if I use the two different builds.
Thank you!
One is built in Release mode and one in debug mode. Now, it depends on you if you are using any tools that catch the logs generated by the app.
In release mode, you cannot get the app's logs, in debug mode you can get the debug logs.
For ex, if you wanna make sure that one particular set of the code block is executed, the developer can put a line of code which writes into log-like 'This code block is executed' etc.
It's best that you use debug since sometime an android app having pro-guard enabled may cause some problems for automation.
Debug build is recommended for testing because the complete symbolic debug information is emitted to help while testing applications because the code optimization is not considered.
I am working with my app in test flight now and I have experienced this maybe only one time myself. How can I get to the bottom of a rare crash without it being hooked up to the computer? The only information is that it occasionally will freeze, but other than that it doesn't seem to be happening with a specific action. How do I debug this?
Here are some approaches:
Write log files to the disk, which you can later sync. or send to a server for investigating which operations succeeded before it crashed
Integrate a custom (such as KSCrash, Crashlytics, etc.) crash reporter tool that allows you to see a backtrace (Note though that enabling Bitcode will make things much harder)
Try to reproduce the problem in the simulator (try different builds, debug build, release build, send memory warnings, etc.)
Try to reproduce with a computer connected. Interactive debugging makes things so much easier.
Good luck!
First of all, I'm sorry to ask a somewhat vague question but I'm only doing it because I'm clueless to what might be causing the problem.
I've been building an app with Sprite Kit and it has worked great. I've made some additions to code at suddently I see a dramatic decrease in performance. I have rolled back all my code changes but the performance didn't go up. I'm left clueless to what's wrong.
After hidious debugging I've noticed that the performance problem only affects run and test builds. If I do a profiling build, the app behaves as normally = with high performance. So this would suggest that my problem is somewhere in the build configuration but I'm completely new to ios build environment configurations.
Can anybody suggest what might be the cause of this? Where should I start looking? I have my background in Java 5 and the compiler and other settings are quite strange to me.
The default setup is to have a Debug config and a Release config, where Debug is configured with no optimizations, and Release does include optimizations. Optimizing often makes it hard to use the debugger, which is why unoptimized code is preferred there.
By default, Run, Test, and Analyze use the Debug config, Profile and Archive use the Release config. Your change in behavior could come from lots of differences: you may have had it configured before to build for Run in Release mode. You may have had a subproject built in Release mode that is now in Debug. You may have made a coding change that is very slow unless the optimizer is used. (Since you say you rolled back the code, this last one is unlikely, but check your version control and see if you changed any project settings.)
If you're seeing weird "it wasn't like that before" behavior when you think you've put everything back, make sure you're rebuilding everything. Delete your Derived Data directory. You can determine where it is in Preferences, Locations. "Delete your Derived Data directory" is the Xcode-equivalent of "try rebooting." It's the most common way to fix strange "Xcode isn't working right" problems. In fact, I put my Derived Data in /tmp/build so that it gets deleted every time I reboot (and so the path is easier for me to remember).
Sometimes I'm trying to track down a really rare bug in an iOS app. I'll hit it in the debugger after hours of trying to repro only to have xcode or lldb crash on me while I'm debugging (usually if I'm stepping through C++ code). This is beyond infuriating.
With gdb you can use generate-core-dump to create a core dump of the file so that I can re-load it in gdb and at least look at all of the memory. What I want is the ability to do something similar in lldb so that when xcode crashes (as it always tends to do at the worst times) I can recover my debugging session without having to reproduce the crash.
The app is running on a non-jailbroken iPhone, so I don't have much access to the OS to do something like dump the memory from there.
One possible answer is to just use gdb instead of lldb, but I think that causes some other problems that I'm not remembering at the moment, plus it doesn't have some of the features that are useful in lldb.
UPDATE: Xcode 6, released fall of 2014, includes a new process save-core command in lldb -- lldb can now generate a coredump of a user process. e.g. (lldb) process save-core /tmp/corefile and wait a little bit.
The original answer for Xcode 5 and earlier lldb's, was:
This feature isn't implemented in lldb yet. This feature isn't implemented in the Apple version of gdb, either, for that matter.
While not a commonly requested feature, it is something other people have said would be useful as well. Hopefully someone will be sufficiently motivated to add that capability to lldb. I'm not sure how well it would work on an iOS device because it's going to involve gigantic amounts of data being transferred up to the Mac over a protocol that isn't very efficient for large data transfers - I expect it would be remarkably slow.
The core file can be opened with lldb -c /tmp/corefile
It's worth noting that the process explorer tool for iOS can generate core dumps of any PID (assuming you have root or it's the same UID as you), without impacting the process.
After running into this issue for the 10 billionth time and nearly whipping my mac air out the window in frustration, I've decided to break down and ask if anyone else has run into this...
Environment: running the latest version of XCode (as of this question: 4.2, build 4C199) for an iOS 4.2+ application (universal app).
It appears that GDB randomly decides to completely hang while stepping through lines of code. This has happened to me now on multiple codebases, and in various locations throughout each codebase. The stepping process hangs on an arbitrary point and requires that the running iOS simulator or on-device process be stopped and restarted. Typically, after restarting my debugging session I am able to get to a different arbitrary point in stepping into/thru -- sometimes even enough to actually debug my code entirely (gasp).
I tried wiping my drive, re-installing a fresh copy of Mac OS X 10.6.8 and the aforementioned XCode... No difference.
I tried switching debuggers to LLDB; this resolved the hanging issue, but I'm not as big a fan of LLDB and prefer to use my environment as close to stock as possible.
Any thoughts?
If GDB is still hanging after reinstalling your OS and your SDK, it may be a design issue with your particular code. Does this happen with other projects?
If it makes you feel any better, Apple is moving to LLDB as the stock debugger for Xcode, probably due to issues like your aforementioned issue.