Found my slowdown. FYI.

Member
Posts: 110
Joined: 2009.07
Post: #1
Since I've been having issues getting the instruments to work on anything but the simulator, I've had difficulty figuring out what's killing my framerate.

I've finally found it by the rather primitive process of turning everything off until the program ran quickly.

The offending line was the line I was using to sort my drawlist in order of textureID:

NSArray *sorted_objects = [drawset sortedArrayUsingSelector:@selector(compareByTextureID: )];

Methinks I'll have to find another way to sort these, or - better - to not bother sorting them at all. I never suspected for a moment that this would be so slow!
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #2
The standard practice is to use insertion sort for that sort of thing. Assuming that you aren't rebuilding the array of objects to draw every frame, it should already be mostly or completely sorted. That is the best case scenario for insertion sort in which case it uses O(n) cpu time instead of O(n*log n) for most sorting algorithms in their average case.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 110
Joined: 2009.07
Post: #3
Thanks for the tip - I'll look it up.

Currently I've re-factored my code so that sprites live in an array associated with a specific texture atlas, meaning that no sorting is necessary. Of course, this necessitates moving a sprite from one array to another when it changes the atlas it refers to, which is a bit slow. However, this is a per-game-tick operation, rather than a per-render-frame operation, so less prone to murdering my frame rate with a large club.

However, I'm now very wary of all forms of obj-c array/dictionary iteration and considering going 'cave man' and rewriting the whole thing with simple structs in straight C.
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #4
Madrayken Wrote:Thanks for the tip - I'll look it up.

Currently I've re-factored my code so that sprites live in an array associated with a specific texture atlas, meaning that no sorting is necessary. Of course, this necessitates moving a sprite from one array to another when it changes the atlas it refers to, which is a bit slow. However, this is a per-game-tick operation, rather than a per-render-frame operation, so less prone to murdering my frame rate with a large club.

However, I'm now very wary of all forms of obj-c array/dictionary iteration and considering going 'cave man' and rewriting the whole thing with simple structs in straight C.

Either use straight C or go for std::vector.
Quote this message in a reply
Member
Posts: 110
Joined: 2009.07
Post: #5
I come from an assembler and C background, so straight C is probably the way for me. Thanks for the confirmation.
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #6
Madrayken Wrote:I come from an assembler and C background, so straight C is probably the way for me. Thanks for the confirmation.

Yeah ... I do that often too ... just remember that std has tons of useful algorithms which often work just fine with regular memory arrays.
This stuff has been written by people who do these kinds of thing for living and you are very unlikely to write code that will outperform std ...unless you have some specific knowledge about your domain problem and are able to code to it, otherwise using std is a much better option.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #7
Madrayken Wrote:However, I'm now very wary of all forms of obj-c array/dictionary iteration and considering going 'cave man' and rewriting the whole thing with simple structs in straight C.

That's what I did too. Obj-C isn't the problem as much as NSArray/NSDictionary for stuff that needs to be tight.

On the C++ route: yuck!

I just recently ported a physics engine from C++ to straight C and got at least a 30% increase in performance. I can say that the primitives you'll find in std are certainly very fast, and likely best in a general sense, but can easily be coded custom in C for any specific purpose (well, maybe except for hash mapping, 'cuz I suck at that Wink ). The *real* problem is in all the extra code that C++ programmers tend to add around trying to solve problems they don't fundamentally understand. There's often a false sense of efficiency and safety, and at times, even flexibility (specifically, using % as an overloaded operator for cross is effing brain-dead; I can't tell you how many times I had to go back up the class hierarchy to determine specifically if it was modulus or cross -- argh!!!). That's not to say C++ isn't fast or flexible, but the perception that it is universally efficient or sound to code in is an illusion, depending on who's doing the coding. Wink
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #8
AnotherJake Wrote:That's what I did too. Obj-C isn't the problem as much as NSArray/NSDictionary for stuff that needs to be tight.

On the C++ route: yuck!

I just recently ported a physics engine from C++ to straight C and got at least a 30% increase in performance. I can say that the primitives you'll find in std are certainly very fast, and likely best in a general sense, but can easily be coded custom in C for any specific purpose (well, maybe except for hash mapping, 'cuz I suck at that Wink ). The *real* problem is in all the extra code that C++ programmers tend to add around trying to solve problems they don't fundamentally understand. There's often a false sense of efficiency and safety, and at times, even flexibility (specifically, using % as an overloaded operator for cross is effing brain-dead; I can't tell you how many times I had to go back up the class hierarchy to determine specifically if it was modulus or cross -- argh!!!). That's not to say C++ isn't fast or flexible, but the perception that it is universally efficient or sound to code in is an illusion, depending on who's doing the coding. Wink

Yeah, C++ is a very complex language and it is easy to shoot yourself in the foot if you just dive into it straight from C. As any language it has its own share of small inconsistencies , little stupid workarounds etc ..

On the other hand, if properly used , allows for very nice looking ( in terms of programmers perception) and very fast code - I mean often as fast as it can get. Code like this:
Code:
Vector3 left=(leftOff*mCommonWidth)*camRight;
certainly is easier to read than :
Code:
Vector3 left;
multiplyVector3Scalar(leftOff*mCommonWidth,&camRight,&left);
I know it is semantics but still, it helps when you have tons of code like that. Not to mention that current compilers are pretty good at optimizing that kind of code and more often than not will inline everything ( which can turn out to be faster than the C based method) Also, the problem with rolling your own collection/algorithm classes in C is that, well you are reinventing the wheel and you will end up making many mistakes on the way ... Another issue is that with C , there is no easy way to generalize algorithms .. the best you can do is with qsort type of approach which very often is going to be slower than a template based C++ solution.

You know ...there is a reason why almost all professional games are written with C++.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #9
Sigh... Well, I could pick apart every sentence you just wrote, but I'm not going to get into yet another C/C++ debate (at least not tonight Rasp ). Needless to say, I strongly disagree with most of your assertions, and for good reasons, which have already been explained countless other times, in great detail, in countless other C/C++ threads. I'm a grizzled C/C++ flamewar veteran who is losing interest in wasting effort trying to set you nut-jobs straight (LOL, I kid about the nut-job comment). I'll leave it to the younger whipper-snappers Wink

[Edit] BTW, I don't hate C++. The language itself isn't anywhere near as dumb as most of the coders who use it. At least 80% of the C++ code I've read over the last 20 years is unreadable crap. That means that to me, only 2 out of ten C++ programmers have any business using it. The rest of them need more experience, or at least better instruction. [/Edit]
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #10
AnotherJake Wrote:Sigh... Well, I could pick apart every sentence you just wrote, but I'm not going to get into yet another C/C++ debate (at least not tonight Rasp ). Needless to say, I strongly disagree with most of your assertions, and for good reasons, which have already been explained countless other times, in great detail, in countless other C/C++ threads. I'm a grizzled C/C++ flamewar veteran who is losing interest in wasting effort trying to set you nut-jobs straight (LOL, I kid about the nut-job comment). I'll leave it to the younger whipper-snappers Wink

[Edit] BTW, I don't hate C++. The language itself isn't anywhere near as dumb as most of the coders who use it. At least 80% of the C++ code I've read over the last 20 years is unreadable crap. That means that to me, only 2 out of ten C++ programmers have any business using it. The rest of them need more experience, or at least better instruction. [/Edit]

Yeah,well, C++ is just a language ... there is tons of crappy code written in any language and frankly, as far as Obj-C, their well written code still looks like a strange mix of C/Smalltalk - as if somebody just quickly hacked a temporary solution on top of C ( which is what actually happened)

But anyway ...I have been writing code for about 15 years as well so I have my own well formed opinion about this subjects ... but in the end all of them are just tools which do reasonable job.

PS.
My original post was not really about using C++ but rather about writing custom C code to re-implement solutions to well researched and understood problems - unless meant as a learning tool, it tends to be very unproductive regardless of what language you are using.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #11
warmi Wrote:But anyway ...I have been writing code for about 15 years as well so I have my own well formed opinion about this subjects ... but in the end all of them are just tools which do reasonable job.

Aha! Tools! Yes, that's where we all agree. I know that C++ has it's place; I use it too from time to time (don't tell anyone I said that). But the reality is that we all tend to be better with different tools. Obviously when someone recommends against my tool of choice, I will feel compelled to step in and counter that (clearly bad Wink ) recommendation. That's just the way it is. Since you've been in it for as long as you have, you know what I mean. Wink
Quote this message in a reply
Member
Posts: 110
Joined: 2009.07
Post: #12
Pah. I've been coding for 25 years. Just to show you guys don't know a real language when you see it, I'm going to rewrite the whole thing in 6502 assembler. That'll show you. :-)
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #13
Madrayken Wrote:Pah. I've been coding for 25 years. Just to show you guys don't know a real language when you see it, I'm going to rewrite the whole thing in 6502 assembler. That'll show you. :-)

LOL Touché. I don't miss assembly. You can keep it Rasp
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #14
Madrayken Wrote:Pah. I've been coding for 25 years. Just to show you guys don't know a real language when you see it, I'm going to rewrite the whole thing in 6502 assembler. That'll show you. :-)

Oh well ... 6502 was a bit before my time but I did start with 68000 on Amiga in the late 80/early 90s ...
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #15
Madrayken Wrote:Pah. I've been coding for 25 years. Just to show you guys don't know a real language when you see it, I'm going to rewrite the whole thing in 6502 assembler. That'll show you. :-)

Pah. Real coders emulate 6502 in geometry shaders Wink
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Symbol(s) not found using oalTouch example code monteboyd 2 3,467 Sep 26, 2010 10:49 PM
Last Post: monteboyd
  Slowdown while playing many OpenAL sounds and accessing AVAudioPlayer.playing Rasterman 6 5,880 Aug 31, 2010 09:46 PM
Last Post: headkaze
  Texture2D class Found Gillissie 1 3,212 Mar 16, 2009 03:49 PM
Last Post: jeonghyunhan
  error: framework not found ApplicationServices kancho 1 3,807 Nov 23, 2008 11:33 PM
Last Post: OneSadCookie