In my app after a while, there seems to be a huge issue. There is a build up of b2Bodys from Box2D. I do use some b2Bodys in my app for collision but I would say there is at MOST 10 on the screen at once.
After I debugged the app with Time Profiler in Instruments, I get this as my biggest slowdown:
So basically it seems that some of my b2Bodys are not getting cleaned up when they should be. Is there any way to NSLog the amount of b2Bodys in the world so I can check if anything odd is happening?
Thanks!
You can add NSLog statements to the appropriate CreateBody and DestroyBody methods in the b2World class.
Related
I have an app that adds a lot of UIClasses to many different Views. Views get removed and get added again. But then after some time working with the app, the app starts to slow down. Reloading everything, including the Viewcontroller, doesn't help.
The problem is, that i don't know what could slow down the app. The Memory Usage of the app doesn't go up and the CPU usage doesn't go up aswell. It just seems that the App does everything slower. Views take longer to get added to the view and so on.
Is there anything that i could check what could cause the app to slow down over time? I know that this question is very broad, but maybe someone of you can show me the direction to look at. I`m out of ideas.
It's hard to answer a question like this in the abstract.
I suggest using the Instruments tool and running a time profile. That lets you see where your app is spending most of it's time. You should be able to run the app for a period of time and see the culprit start to take more and more time as you run the app.
My app gets stuck for a specific operation and that operation is too big having so many method calls and services requests, so i cannot put breakpoints on each method and debug, is there any other way i can get to know where exactly my app is stucked in xcode?
The operation wasn't too big to write the code, so it isn't too big to add breakpoints, logging statements, assertions and so on.
The only other way that works sometimes is taking a long shower in the morning, not thinking about work at all, and suddenly the realisation what you did wrong jumps to your mind. It has worked for me sometimes, but the first method is more reliable.
If you have reason to believe that the most time is spent in one operation, just let it run with the debugger attached and then press the pause button and see where you are...
A somewhat niftier approach would be to start with Instruments (i.e. the Time Profiler). It's easy to use and should be the first weapon of your choice for performance issues.
You can set a conditional break point in Xcode to debug a specific condition, for more detail go through Jeffrey Sambells blog!
Since moving to iOS 8.3, I'm encountering this error where the main thread will get stuck in this call. A few other threads are also stuck in that call. There is none of my code in any thread that leads to this call, so I'm stumped as to why this is happening. It happens randomly, sometimes, when tapping a button bar item, sometimes while redrawing charts (using ShinobiCharts), etc.
Here is the stack trace from Xcode:
Anybody has any clue as to why this is happening and how to fix it? It's very annoying because when I get stuck there, I have to relaunch the app. Note that this is happening in the simulator so far. I'm in the early stage of developing this app and spend most of my time in the simulator. I haven't seen the error happening yet on a real device but, again, I haven't run the app that often on the device.
Knock on wood, but I think I figured it out (at least in my instance).
What led to the solution was a search for syscall_thread_switch, which led me to this answer here:
https://stackoverflow.com/a/30333203/978509
Which, if you look at the backtrace I linked (https://gist.github.com/Shalmezad/65ff89d20aa7e0a9d094), every syscall_thread_switch is preceded by OSSpinLockLockSlow, which the answer notes looks like Livelock, but due to the low CPU usage, is more evident of a deadlock.
Going through my code, I found that for every background task, I created a new dispatch_queue_t each time. I since redid how that works to use the same queue, which seems to have fixed the issue.
Without further information from nemesis (mainly some code snippets showing how he's setting up background tasks), I cannot answer their specific question, however this should point people in the right direction for fixing the issue.
I am building an iOS game and I notice that the game performs fine while running normally in the XCode debugger. However, when i run it from within Instruments (Product-> Profile to trace Leaks), the game freezes when Instruments displays 'Analyzing Process' in the left sidebar. After that the game messes up all its state since some parts of the game that were being analyzed froze up while other parts kept going.
Is this something I can/need to fix or is it sufficient to make sure the game runs in release?
If a fix is needed, what do I need to do to make it work?
Update 1:
So we found the issue - the same problem repros even if we are playing the game, press the home button and click on the game icon and continue playing.
The issue is that most of our work is done in the update method, and it relies on the value of the (ccTime)dt parameter. The value of dt is usually < 0.1 seconds, and occasionally somewhere upto 0.5 seconds).When we pause (either by clicking the home button, or when instruments pauses the game to take a snapshot) and resume playing, the value of dt is several seconds! And that throws all our calculations out of range.
We tried a temporary (but ugly) workaround that fixes the issue: at the beginning of the update method, we add this:
if(dt > 1)
return;
And it now works as expected - doesn't go out of sync. However, this is not a permanent solution, since sometimes, the values of dt are legitimately close to 1 second, and in resource crunched situations, this may lead to stutter (or worse).
We also considered another (equally ugly) solution of storing the previous value of dt, and then check in the update method:
if(dt > 10 * prevDt)
{
return;
}
We tried calling unscheduleUpdate in AppDelegate.m's applicationDidEnterBackground, and called scheduleUpdate in the applicationWillEnterForeground method, but that approach did not work.
What is the best way to deal with updates with erratic time values due to external pauses?
Thanks
Anand
I don't know much about how cocos2D works, but if you've run out of options, I would simply clamp the delta time to an upper range. In whatever update methods used delta time, I would do the following.
double delta = (dt > 0.5) : (0.5) ? (dt);
Use delta instead of dt from that point onward. The result is that any frame with a delta of over half a second will be limited to a delta of half a second. You don't want to skip frames, because then you could potentially skip many frames in a row which would be bad for the user; they'd probably think the app crashed or something. However, you don't want to run a frame with a large delta because then delta-dependent objects and forces will get multiplied many times for that frame, preventing you from catching collisions and stuff. So, we prevent the game from getting completely screwed over while not skipping frames by simply clamping the value downwards.
The negative is that the app will appear to move more slowly when your frame rate drops to 2 frames per second. You lose the benefit of a time-based update method, which is the ability to always make the game appear to run at a well defined speed, when the engine is overburdened.
To be honest, if you ever run at 2 frames per second for an extended period of time, you've got bigger problems to worry about. I don't think the user will notice if objects move slightly more slowly per second if the game is only rendering once every who-knows-when anyways.
Unfortunately this is a problem, for which there is no sure answer; at least not without access to your system to run a whole variety of checks.
The failure in the profile may be because your game is running tight loops the timing of which get's upset in unpredictable ways and your game is crashing due to timing or resource issues (where those timing issues don't crop up with the debugger in the same way). If that's the case, there is probably not much you can do about it. Or it may be because there is a problem in your code. The problem is it can be very difficult to figure out which of these is the case. It's probably best to assume the problem is in your code though and do some further investigation.
The first thing to do, if you haven't done it already, is run the static analysis tool (Analyse from the Product menu in Xcode). Consider each of the raised errors carefully, and work to remove all of them. Sometimes they might seem obvious and you think you can ignore them, but some prodding reveals they are a symptom of a deeper problem.
If you haven't tried already, try running the instrument to check for zombies. There's a high chance this will fail also if the allocation instrument is failing, but if there are some stale references to de-allocated objects hanging around they could be causing the problem you are experiencing. Another instrument you can try is the performance analyser, to check where your app is spending most of it's time. There may be some really significant problem with the overallocation of resources you are not aware of. If you can't run the memory profiler, it will be difficult for you to see if this is the case, but using the performance analyser, it might be possible to see if your app is getting hung up for too long somewhere it shouldn't be.
Lastly - if all else fails and this may be a sledgehammer to crack a nut - and also may not in any case provide the solution. If you aren't using ARC, consider how long it would take to convert your app to using it (definitely create a branch first before doing it though). The Apple algorithms for object allocation/deallocation are very efficient and there is a very good chance if you have subtle memory management errors, they will be eliminated by Automatic Reference Counting.
I've recently finished my first iPhone app that I'm actually planning to submit, and I'm trying to clear out all the leaks. However there's one that I just can't seem to track down, and Instruments isn't really helping me either. Essentially, I've made something like a to-do list app (that's not really important though) and every time a user deletes a to-do, instruments registers a leak.
Instead of me trying to explain further, here's a screenshot:
http://dl.dropbox.com/u/1426380/Screen%20shot%202011-02-09%20at%2021.51.09.png
So instead of telling my exactly where the leak is coming from (like with previous leaks I've fixed), iInstruments just points to somewhere in the foundation library. It's only leaking 16B each time, so it's not really an issue of crashing, but I'm simply interested as to what is causing this.
I would love to post some code, but since I have no idea where the leak is originating, I have no idea what to post. If someone had an insight on what might be causing this, I'd be happy to oblige.
Thanks.
EDIT:
Here's another screenshot as requested by #Moshe. I'm new to instruments so I didn't even realise that the right panel existed until now!
http://dl.dropbox.com/u/1426380/Screen%20shot%202011-02-10%20at%2007.55.58.png
I suggest running "Build and Analyze". (In the Build Menu, or ⌘ + shift + A).
If that returns nothing, it could be that an Apple framework is leaking. If that is the case, there is nothing you can do.