The Fastness of Classes
Author
Hi
I was diong some experiments with DirectDraw, writing to screen memory, and I found that if I used Classes and Methods for something like a Color that I got half the frame rate than when using Structs and Functions. also if I used any global variables in a function it slowed down as well.
Can anyone explain this? Why use C++? Am I using it wrong?
Ro
You are probably doing something significantly wrong. Member functions are only generally slower than normal functions in that they implicitly pass a ''this'' pointer - but usually you end up passing a pointer to the relevant object in a global function anyway so this is very rarely a loss. Passing a class to a function is identical to passing a struct, so there''s no reason that would be any different... Using derived classes can start to incur vtable overheads, but to be honest, to get the same functionality in C would require a similar solution which is unlikely to be any faster.
Maybe you could post some of your code. There''s no reason for such a slowdown. A heavily Cplusplused (is that a verb?
) program shouldn''t really demonstrate any more than 1% or 2% slowdown.
Maybe you could post some of your code. There''s no reason for such a slowdown. A heavily Cplusplused (is that a verb?
) program shouldn''t really demonstrate any more than 1% or 2% slowdown.
Perhaps your having some default constructors called for a temporary object inside a loop. That''s a push/call/ret/pop every iteration. If so, do something like this:
for(i=0;i rgb color(r,g,b);
// do something with color
}
or:
rgb color;
for(i=0;i color.set(r,g,b);
// do something with color
}
Hope this helps!
for(i=0;i rgb color(r,g,b);
// do something with color
}
or:
rgb color;
for(i=0;i color.set(r,g,b);
// do something with color
}
Hope this helps!
Sorry, the post messed up. The idea was to either initialize the color var when it''s created, or move its creation outside the inner loop.
Even so, a default constructor for a class shouldn''t be any worse than a default constructor for a struct with the same members. And global variables shouldn''t slow anything down at all. Something else must have changed, I think.
I''ve heard that when you define a method in the .h file (immediately in the class{} block), it''s always compiled as an inline function, which is supposed to be much faster that a function defined outside the class{}. If it''s true (is it?), it''s maybe the key to Rowbot''s problem?
If you are using classes for Color, then creating an array of them to represent an image, that could be a problem. I would not use any virtual functions in the class, as that automatically adds four bytes (on a 32-bit OS) to its size. virtual functions go through a table of function pointers rather than directly calling the functions. To keep this table (once for a specific object type) requires a pointer to the table, which is stored (hidden) in the class.
What all this boils down to is that if you are creating a Color class as follows (with the VC default class insert option):
That class''s data is 3 bytes, plus the 4 bytes for the virtual function table, because of the virtual destructor. Eliminate the virtual destructor, don''t derive from the class, and don''t use virtual functions, and it should be fine. Regular and static member functions (including operators) work great though. This rule only holds true for small classes (data-wise) that are going to be allocated in large arrays. virtual destructors (and all virtual functions, for that matter) are only necessary when you are deriving classes from it.
For that class I listed, it was using 133% more memory than if you had left out the virtual destructor. So, allocating an array of 640x480 would mean using approx. 2 MB instead of approx. 0.75 MB. In normal circumstances where the class allocates more memory than its own size or only a few objects of the class are in use, the increased memory size of virtual functions (then a measely 4 bytes) is trivial.
- null_pointer
Sabre Multimedia
What all this boils down to is that if you are creating a Color class as follows (with the VC default class insert option):
class Color
{
public:
Color();
virtual ~Color();
protected:
unsigned char m_cRed;
unsigned char m_cGreen;
unsigned char m_cBlue;
};
That class''s data is 3 bytes, plus the 4 bytes for the virtual function table, because of the virtual destructor. Eliminate the virtual destructor, don''t derive from the class, and don''t use virtual functions, and it should be fine. Regular and static member functions (including operators) work great though. This rule only holds true for small classes (data-wise) that are going to be allocated in large arrays. virtual destructors (and all virtual functions, for that matter) are only necessary when you are deriving classes from it.
For that class I listed, it was using 133% more memory than if you had left out the virtual destructor. So, allocating an array of 640x480 would mean using approx. 2 MB instead of approx. 0.75 MB. In normal circumstances where the class allocates more memory than its own size or only a few objects of the class are in use, the increased memory size of virtual functions (then a measely 4 bytes) is trivial.
- null_pointer
Sabre Multimedia
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement