Compile For Thumb == bad
I might be an idiot, but I didn't realise just what a difference this little checkbox in the target properties can make.
Anyone doing any floating point math that needs to be fast, (i.e. developing games) should absolutely uncheck this. It more than doubled the frame rate of DuckDuckDuck, with the rather minor inconvenience of an increased binary size.
Others have mentioned this before, but I finally got around to comparing the difference and in my case it was huge.
Anyone doing any floating point math that needs to be fast, (i.e. developing games) should absolutely uncheck this. It more than doubled the frame rate of DuckDuckDuck, with the rather minor inconvenience of an increased binary size.
Others have mentioned this before, but I finally got around to comparing the difference and in my case it was huge.
Chopper, iSight Screensavers, DuckDuckDuck: http://majicjungle.com
Dang, I just tried it and noticed no real change. 
Back to trying to enforce my will to get a steady 30 fps no matter what.

Back to trying to enforce my will to get a steady 30 fps no matter what.
Was definitely a noticeable speed bump (10% maybe) for ScribBall, but certainly not double. YMMV.
Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
yeh in DuckDuckDuck my biggest performance bottleneck was in doing large amounts of floating point math within nested loops.
Shark pointed this out, and the magic checkbox worked wonders. YMMV indeed.
Bachus: Have you been using Shark to pinpoint your problems? It's (to put it nicely) not very friendly to work with when profiling iPhone apps. I can give some pointers on how to encourage it to actually give you something useful if you'd like.
Shark pointed this out, and the magic checkbox worked wonders. YMMV indeed.
Bachus: Have you been using Shark to pinpoint your problems? It's (to put it nicely) not very friendly to work with when profiling iPhone apps. I can give some pointers on how to encourage it to actually give you something useful if you'd like.
Chopper, iSight Screensavers, DuckDuckDuck: http://majicjungle.com
Yea, I've been using Shark pretty religiously for the past week to try and track down any possible speedups. I've gotten up to a fairly steady 20fps with the occasional dip to the low teens. Trying to get to a fairly steady 30ish with the dips no lower than 20. Getting close, I was just hoping that the thumb trick would be a magic bullet. 
If there's one thing I've learned it's that no matter how fast you think a particle system can be, it can always be faster.
EDIT: Oh, here's one thing. Does -falign-loops=16 actually do anything? Shark's always bitching about that, tried adding it, and Shark still bitches.

If there's one thing I've learned it's that no matter how fast you think a particle system can be, it can always be faster.
EDIT: Oh, here's one thing. Does -falign-loops=16 actually do anything? Shark's always bitching about that, tried adding it, and Shark still bitches.
Dont use NSTimer, instead start a new thread and run the rendering loop in the thread. This will give you an automatic 15-20% speedup (well, those are my benchmarks).
tn2230 mentions this:
Quote:Note: iPhone supports both ARM and Thumb instruction sets. Although Thumb reduces the code size, be sure to use ARM instructions for floating-point intensive code for better performance. To turn off the default Thumb setting in Xcode, open the project properties and uncheck the Compile for Thumb build setting.
I have discovered, that it actually gets about 30%, which is pretty nice as there's not much floating point in my game. Particle effects/emitters flow probably the only what eats CPU power. It looks like opengl blitting also improved, though it's only an impression.
However, using memory instrument I can see extra 5 Mb in overall net usage on the simulator. (was 34, now 39). Haven't tried on a device though - these 3 minutes before it deploys and run practically eat my brain.
However, using memory instrument I can see extra 5 Mb in overall net usage on the simulator. (was 34, now 39). Haven't tried on a device though - these 3 minutes before it deploys and run practically eat my brain.
jaguard Wrote:I have discovered, that it actually gets about 30%, which is pretty nice as there's not much floating point in my game. Particle effects/emitters flow probably the only what eats CPU power. It looks like opengl blitting also improved, though it's only an impression.
However, using memory instrument I can see extra 5 Mb in overall net usage on the simulator. (was 34, now 39). Haven't tried on a device though - these 3 minutes before it deploys and run practically eat my brain.
3 minutes? WTH! I have over 50 apps installed on my device and my app launches from within a build&run in XCode on the device in ~ 20-25 seconds.
Are you running ancient firmware?
bhammond, I'm scared to upgrade SDK from 2.0 - I've read topics that some people experienced troubles when upgraded. If I ruin something on this mysterious OS(aka mac os), I would have no idea how to fix it
.
.

