Forget face value... Kendric's statement is totally false! Objective-C is not "slow". What is slow for games is Cocoa if you use it wrong (e.g. don't be using NSArray in games!). Do not confuse performance of Objective-C (the language) with Cocoa (the API).

You cannot deny that objective c is slower then c\c++ by more then a negligible amount for core language features. Forget about NSArray. That was the only thing in my code I think that I used that was coaca. I was still able to optimize my performance incredibly by removing obj c code and replacing.
If you do
for(int i=0;i<10;i++)
{
[ob isSomething];
}

where isSomething simply returns a bool, you will have a significantly slower time then if you did it in c.

I had this in my code where all that happened in isSomething is 1 line, return someVar; and I was getting a large % cpu usage on that line in shark. Infact I even saw performance bloat from using a synthesized function vs doing my own implementation. Maybe shark was giving me bogus info but that's what It said.

You can't claim that a language is fast if you are constantly having to decide if you want to revert back to the c superset to avoid bottlenecks.

A language is fast if it can perform high intensity tasks with minimal overhead. A language is slow(er) if it cannot. The speed of a language is not dictated by what the task is, its a general statement. Program the same thing in assembly, c, java, and objective c and you will be able to determine something about their relative performance.

I never said don't use objective. I said to use c for framerate reasons. If you are not worried about framerate(for example your writing a low intensity app) then it wouldn't apply. I also said consider, that doesn't mean its 100% hard fast rule.

I'm sorry, but according to the impression I've been getting from your posts on it lately, you do seem to recommend against it:

Quote:Objective c is very slow for things that need to pull off 60 frames per second.

Objective-C is plenty fast enough to use and get high frame rate on iPhone, it just depends on how you use it. I saw in that other thread that your perception of Objective-C's performance was based upon how you were using it with Cocoa, which is completely misleading -- do not use Cocoa in performance critical areas! Also, there's no sense in doing lots of Objective-C messaging in tight loops either (although there optimizations that can be made there). That does not mean one shouldn't use Objective-C, and it doesn't mean Objective-C is too slow for games.

I can give you a history of how I used objective-c and what problems I am facing because of it, and then you can advise me if I did not use it correctly or have any suggestions.
I wanted to make my game engine a very elegant OO solution. I setup the following hierachy (this is 100% objective c class structure)

Each game object has a passTick function in it, and in there they can manipulate things, often multiple levels up their inheritance hierarchy.
What this results in is a lot of messaging. Each guy also is ading his custom flavor to the game logic and all of those require many gets and sets of variables that are private in super classes. This results in more messaging. Sure I could do this all procedurally, or make everything public or something like that, but that defeats the whole purpose of doing it OO. The other thing is all that stuff has a matching protocol hierarchy to create separation of implementation and interface. Thus I am likely getting another performance hit for obj-c having to translate those(I looked at what was involved in the assembly for an instanceof id<ISomeInterface> to be created and assigned and it seemed like quite a few commands.

This type of behaviour is what leads me to see the large %cpu usage in the obj_c_message thingy in shark and why I am concerned about using this in high intensity games. Sure you could write wrapper code, some glue, couple high level things, and do the rest in c, but then you aren't really the subject of my comments since your doing most everything in c\c++.

I meant to add, with this complex structure, the game loop encompasses tons and tons of code. You cannot simply not use objective c in the game loop when your programing it OO like I did. How would you talk to your super classes, and how would you access values on objects you want to talk to? You could argue not to program it like this but then why are we using an OO language? The fact that my game setup allows me to add to it super easily without any work is what made objective c so appealing in the first place.

"Objective-C is plenty fast enough to use and get high frame rate on iPhone, it just depends on how you use it."

I think that's absolutely true. But I also think that if you code in C, you end up programming in ways that help the speed of your code. It's a matter of removing abstractions that prevent you from seeing what's happening when the code is compiled.

As a historical analogy, I've seen people write code C and then translate functions into assembly. They have a hard time getting much of a boost. But if you start in assembly in the first place, you see ways to organize your data differently that you don't tend to see in C.

I'm not saying anyone should be writing a game in assembly anymore, but I am saying that the choice of language and the habits you develop in it can absolutely affect performance. I moved a whole group of functions from Objective-C to C and got a huge boost, but mostly because of a change in perspective, not because of any individual choice or problem with Objective-C.

If you code in Objective-C, I think it's worth the time to write things several different ways and learn which things are slow and which are fast. Getting rid of the worst few performing habits of usage will probably get you close to C speeds.

Quote:Quote:
Originally Posted by Nosredna View Post
I used OpenGL. Objective-C for anything to do with API calls, and plain old C for game logic and calls to OpenGL. Worked great.
FWIW, yes, that's what I do too. Performance is excellent.

For me opengl and game logic is like 90% of my code. How about you guys?