I have an iOS application that is exhibiting performance issues. The problem is that the developers can't reproduce it. And the user who can reproduce the problem is physically nowhere near the developers. This means we can't use Instruments to help debug the problem.
Is there anyway we can do method level timing?
You can say to the person who makes the proves and have the issues that send you the debug log of the crash. The developers could try to find the problem with it.
Related
I am currently developing a project and I'm working in debug during development.
Typically, I'm just working in release mode before I am releasing the next update to check if everything works as expected.
During the last release tests, I found a bug that just appears in release mode.
As soon as I set the optimization level to 1 or higher (I'm using LLVM 4.2), the bug starts to appear.
I don't have any clue what the error could be related to.
Does anyone have an idea what I could do to find the reason of the error?
Instruments maybe? Didn't find a mode that would fit.
It's a performance-related error and I can't seem to find it with breakpoints.
My first guess is that the main thread is running full so that not all events can be processed in time.
If that was it, why would that not happen in debug mode?
I'm working on porting an app from iOS to WinRT/8 Metro/8 Immersive/Whatever the current name is.
On iOS, we have the ability to set Application does not run in background to YES to cause the app to actually quit whenever the user leaves the app.
I would like to figure out how to replicate this behavior in WinRT.
Yes, I understand that this is abnormal behavior.
Yes, I have thought this through.
Yes, I have an extremely good reason for doing this.
I'm assuming that during the userLeavingApp event, I would just call Application.Current.Exit(), but I can't seem to find the userLeavingApp event. I thought about using OnSuspending (Handles Me.Suspending) in App.xaml.vb, but that doesn't seem to be called quickly enough for me.
Is there a .NET equivalent of viewWillDisappear or something?
Any ideas? This is an important security characteristic of my app, and I'd hate to have such difficulty in an entire platform due to such a small issue.
Thanks!
I'm not actually seeing Application.Current.Exit() working in OnSuspending; although as you mention the suspending isn't happening fast enough for you (which is by design). Throwing an exception there didn't work for me either.
There is Window.VisibilityChanged and if I issue Exit/exception there, it does shutdown the app when another app takes over. That said, VisibilityChanged will fire under other circumstances too so not sure if you could cover all the scenarios or rely on them not changing. See here for a bit more context.
To echo #Filip, whose response just popped in, it's highly unlikely you'll pass certification. An Exit() call is tantamount to an exception.
I don't think your app will pass certification if you call Application.Current.Exit(). If you are really confident this is what you want - I guess it is worth a shot to try. You could though simply unload anything that uses memory/CPU when you exit.
So i have been having the hardest time getting my iphone application approved. And i sorta when on a little rampage through some of my code.
In my shear stupidity I thought that maybe I did not need the SenTestingKit.framework. So i attempted to remove it from my program, and when asked if i would like to delete or remove references i accidently clicked delete.
However upon reviewing some crash logs PRE-Deletion of SenTestingKit.framework I found the following...
Again this error was before I deleted the framework. The crash code to this is 0xe7ffdefe
Could someone please tell me where i might get the sentestingkit.framework from? And also if you have anyidea why it is causing the crash that would be so amazing to hear.
Thanks!!!
To restore that framework, just re-install Xcode. Or maybe your trash still has it.
About the iOS devices that complain about not finding the SenTestkingKit: I'd assume so, as it's a Xcode-only framework used for test cases. You aren't supposed to link it when distributing the app. Why would the user want to run test cases?
I'm currently migrating the Fragaria framework from a GC-only environment to GC being supported. After the work was done (or what I thought had to be done to make it work) I was able to run the examples that come with the framework without any problems and Instruments didn't show any major memory leaks.
I included non-GC Fragaria in my non-GC application and it crashes as soon as I place the cursor on it. To be honest the usage pattern is different from the examples as I'm embedding it in an instance of NSViewController instead of NSDocument.
Can you give me some tips on how to debug this? I'm a bit lost on where to proceed now.
First thing to do is Build and Analyze the code, then fix any problems it finds.
Next, try running with Zombie detection enabled (google NSZombie).
Finally, each crash's stacktrace should give you a pretty good idea where things have gone off the rails.
I've been working on a new app, and when I run it on the simulator, it's VERY slow. There's nothing fancy in the app, just UINavigationControllers and text. The slowness only occurs if I launch the app from Xcode (with or without debugging on, doesn't matter). If I run the app on my iPhone or launch it directly from the simulator by clicking it's icon from SpringBoard, the performance problems all disappear.
For what it's worth, all my other apps perform just fine when run launched from Xcode in the simulator, so it must be something specific to this app. Has anyone experienced this before?
UPDATE: There is no performance hit when the app is run through Instruments either. I'm not using any 3rd party libraries. It's all calls to the Apple SDK.
Thanks,
Arash
Have you looked at it in Instruments to see where it's spending its time? No reason to guess when you can test.
Running an app in the simulator while in active debugging will always make the app slower. Always, and in a way that is exactly what you are describing.
Basically, "Build and Go" will be slow because its running the debugger.
This is different from "Debug" vs. "Release". The debug build will run fast if you aren't actually debugging it.
Are you using NSLog() to print a large amount of information? When you launch through Xcode, that information is piped to the debugging console and, if there's a lot, will take time to update the window. When you launch directly or on the device, the data is simply stored in a file, which generates less overhead.
I once reduced a program's run time from several minutes to a few seconds simply by removing logging statements. Unfortunately, it was for a timed programming contest.
I had the exact same problem and spent about 2hrs now to solve it. In my case I think it was because I had "Enable Guard Malloc" set. If it wasn't that, my other guess is bad karma.
Simulator Debug, You should need to be ensure when your app running on simulator debug->slow animations isn't check marked