GP2X Performance Cost Of Ood On Gp2x

[vaustein]

I have a C++/SDL project that compiles in both GCC and VS6 and runs without code modification on both Linux and Windows. I wrote the code to be portable but not object-oriented. I'd like to rework the code according to object-oriented design (OOD) principles. However, I'm concerned about the possible performance hit on the GP2X w/ ARM processors clocked at 200MHz + the 64 MB memory (sic?).

This project is a pseudo-3D dungeon crawl with graphics ripped from Forgotten Realms Unlimited Adventures (FRUA). Underneath is my own decent Rogue-like dungeon generator that creates fully-connected levels. This isn't real time - movement is stepwise just like w/ FRUA - so OOD is unlikely to impair performance. Still, what is the thinking around the performance cost of OOD on GP2X?

 

[Mudi]

Most OOD stuff is 'free' using g++... you should only get hit if you use virtual functions, and even then I wouldn't think it would be a huge performance hit.

 

[ldesnogu]

OO always has a hidden cost that may hit you hard unless you know very well how code is generated.

On top of the virtual dispatch problem Mudi mentionned, often people don't see the price of inheritance: every instance of a derived classe has all its fields plus the fields of all of its mother classes. If you don't pay attention, you end with big objects in which many fields are useless.

As an example, I recently played with SystemC (a library for building simulators); I removed all the unneeded fields and stuff I didn't care, and flattened the hierarchy. End result, the simulation engine is more than three times faster (and compiles ten times faster).

However if you feel well with OO, go with it, just know it has a price

 

[gmiller1018]

There is no free lunch and everything will cost you something but a good design that does not use features just because they are "there" can be done both ways. If you use a feature you need to know what it will cost you and decide to use it or not based on that know cost.

 

[Parkydr]

Few tips:

1. Avoid creating objects
2. Use initialiser lists rather than setting values in the constructor so values are initialised at creation
3. Pass classes as const references to avoid temporary copies
4. If things are really tight, don't use virtual functions although it only adds 2 memory reads

Don't get too hung up on performance - design it, measure it and refactor. As I said before it's another of those 80-20 rules - 20% of the code uses 80% of the resources. If you try and guess the bottlenecks, most of the time it's in the 80% that doesn't matter.

 

[synkro]

AFAIK, using OOP reduces the optimal parameter number for methos to three instead of four in C (vtable entry?!)

 

[Parkydr]

Probably because of having to pass the "this" pointer

 

[gmiller1018]

Yes the first register is the "this" pointer for member functions by definition in the ARM calling standard (first 4 32 bit registers hold the first parameters (the 32 bit ones or two registers for 64 bit "ATPCS"), the rest are pushed on the stack).

 

[rabidcow]

[*]Avoid creating objects

You should understand the complexity of the constructors/destructors that will be called. Allocating and freeing stuff on the heap isn't fast, but on the stack it is.

AFAIK, using OOP reduces the optimal parameter number for methos to three instead of four in C (vtable entry?!)

The cost of putting the extra parameters on the stack isn't all that much. Besides, most of the time you need a way to get at that data anyway, so "this" is replacing a parameter rather than adding one. (otherwise you'd make the function static)

You may need to drop "object orientedness" in some time critical loops, but otherwise I wouldn't worry about it. Just don't go crazy adding 50 million classes any more than you would add 50 million functions without OO.

 

[gmiller1018]

The parameter count issue only impacts the calling efficiency not the efficiency of the function or member function being called. Like most people say do an efficient design then test and see where you need to spend time.

 

[Zettablade]

It's just a matter of design vs speed. Do you want an elegantly designed program with tons of functionality, or an extremely fast, optimized program that doesn't do much...

 

[Blah]

You should make the most elegant OO prototype you can, to have more understandable code to work with. Elegance does not mean excessive features. Then factor out what you cannot afford. It may work well enough as is, you might not have to change anything. If its fast enough, classes are your friend.

Also it is possible to optimize without making clean code overly messy. Use free, helpful tools such as comments and defines to make the optimized bits more understandable if necessary.

If you don't design your code as if someone else was going to maintain it, you will start to forget how things work and then you will be lost.

Also, if you don't agree with me, please tell me what you disagree with. I too would like to learn.

 

[yaustar]

I found this somewhere on my travels. Might be useful. The thing to avoid most is multiple inheritence (barring pure interfaces). Also, try and keep inheritence hericachies as flat as possible.
http://www.tantalon.com/pete/cppopt/main.htm