Here's an interesting blog post about using ObjC++ to improve performance in iPhone apps. I may be in a minority on this, but I've never been a huge fan of the Objective-C++ language. Why straddle yourself with the limitations of two languages?
Okay, that's an over-simplification; there are times when Objective-C++ is a great choice, especially when you are writing the Mac or iPhone version of an application that runs on multiple platforms. It wouldn't however, be the first option that leapt to my mind as a tool for optimizing a poorly-performing iPhone application. Although C++ does some things, like message dispatching, faster (well, technically it's a "vtable lookup" on C++, not a message dispatch), it still incurs some overhead for those things so, it would seem to me, any optimization in C++ is going to leave some room for further improvement. Any way you cut it, though, there's definitely some really valuable stuff in that blog posting in terms of iPhone coding and performance, so go read it.
I'm in the middle of re-writing the drawing code for my particle engine to be faster and am dealing with some of the same issues this blog post talks about, however I chose a slightly different, more old-school option for my optimizations: static inline C functions and structs for the really time-sensitive stuff, and straight Objective-C for anything that isn't time sensitive. Sure it can be a pain to debug, but I only move code into an static inline function after I've had it running inside a regular method or function first. I use the structs to avoid the object creation overhead on things like particles, which there will be a lot of.
So far, it seems to be a good choice - I've had a 2,000 particle per-second generator with a 12-second particle-lifespan using GL_POINT rendering running at 20 frames per second on a first-generation iPhone without much noticeable skipping, which is a huge improvement over my first version, which skipped with even a few hundred particles per second. I'm hoping I see similar improvements in the other rendering types when I finish re-writing those.
Monday, January 19, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment