Observer Pattern and Performance questions

1) I am implementing a cpu-intensive class for image processing (motion detection) and when motion is detected an event is fired to a class MotionHandler that has a virtual function onMotion() that is called many times. How can i improve this virtual function situation? (i heard that calling virtual functions is expensive, is it true?) And can i inline that virtual function?

2) I always heard that i can improve my software performance by writing compiler-friendly code... but what the heck is that :P, how can i do it?

3) Will inlined functions always improve my performance? When it will or wont increase performance?

4) Pointers to classes (MyClass* ptr) are slower than "pure" classes (MyClass ptr)? If it is, how much is it slower than the other way?

5) Know what things cost - The principle of real time programming. But, how can i know it?

Thank you, i would really aprecciate some help =).

Quote:

---

Originally Posted by Scarvenger

1) I am implementing a cpu-intensive class for image processing (motion detection) and when motion is detected an event is fired to a class MotionHandler that has a virtual function onMotion() that is called many times. How can i improve this virtual function situation? (i heard that calling virtual functions is expensive, is it true?) And can i inline that virtual function?

---

If your class is CPU-intensive I hardly think the virtual function call overhead is going to matter at all. It basically amounts to two additional memory accesses. Compared to what I suspect is happening inside onMotion(), that's got to be miniscule.

Quote:

---

2) I always heard that i can improve my software performance by writing compiler-friendly code... but what the heck is that :P, how can i do it?

---

That's a far too abstract statement to explain in any meaningful way. We could give specific answers to specific questions...

Quote:

---

3) Will inlined functions always improve my performance? When it will or wont increase performance?

---

Ultimately it's up to the compiler to inline functions, you can only really hint at it. Generally only very simple functions can benefit a lot from inlining.

Quote:

---

4) Pointers to classes (MyClass* ptr) are slower than "pure" classes (MyClass ptr)? If it is, how much is it slower than the other way?

---

That is in no way true. In both cases, the "this" pointer must be passed as a hidden first argument to a member function. Calls through a pointer or reference might be virtual, which is only slightly more expensive, but you only pay that difference if the function is, in fact, virtual. Even then, it's the virtual call mechanism, not the call-through-pointer, which gives the overhead.

1) Using anything in a circumstance where it is unneeded is expensive, but using it in a circumstance it is suited for is good practice. If you need the actual behaviour of a virtual function (i.e. making a function call, in which the actual function depends on the type of object it is acting on) than it is a good bet that most alternative methods will be more expensive than a virtual function. The only circumstances in which virtual function calls can be inlined is if the exact type of the object it is acting on is known at compile time. In most circumstances, that is not possible. For example, code that only receives a pointer or a reference to a class with a virtual function (as the compiler has no way of knowing if the reference/pointer is to the base class or a derived class) can probably not inline the virtual function call.

2) Writing compiler friendly code means using code constructs in your programming language as they are intended to be used, and avoiding hand-optimising your code any more than necessary. As a rough rule, the compiler (which is written by people who know a lot about both the programming language and about the target platform your program will run on) can do a better job of optimising code than a human can. And hand-optimised code tends to introduce strange constructs, and make it difficult for the compiler to do optimisation. Compiler friendly code tends to make use of functions (while avoiding too many small functions), avoid using global storage (as access to global variables tend to limit the ability of the compiler to generate efficient code, as it must assume those globals can change outside control of the code), minimise use of volatile variables, and be very selective about use of pointers (pointer intensive code can introduce aliasing, and aliasing makes it difficult for a compiler to optimise performance of code). There are many other techniques that fall in the category of "compiler friendly".

3) Inline functions do not necessarily increase performance. The circumstances in which inlined functions increase or decrease performance depend on your compiler. Also keep in mind that compilers are free to decide not to inline a function (inline is a hint, not a directive).

4) As for virtual functions, the relative performance of using pointers vs (in your words) "pure" classes depends on what your code is doing and on behaviour of your compiler. In C++ (particularly with member function calls) it makes little difference, as member functions implicitly receive a "this" pointer anyway .... and all member functions implicitly use it.

5) Realtime programming means developing so that code meets hard timing constraints (i.e. if those timing constraints are not met, the program does not function correctly). Timing constraints can be lower bounds (eg if something occurs too soon, the program does not function as intended) or deadlines (eg if something occurs too late, the program does not function as intended). Realtime programming is actually a misnomer -- the key to developing a realtime system is actually the analysis of timing relationships within the overall system that occurs before the code is written.