C++: Performance impact of BIG classes (with a lot of code)

Question

I wonder if and how writing \"almighty\" classes in c++ actually impacts performance.

If I have for example, a class Point, with only uint x

Answer 1

Member functions are not copied along with the object. Only data fields contribute to the size of the object.

Answer 2

I suppose this is more of an answer than you're looking for, but here goes...

SO is filled with questions where people are worried about the performance of X, Y, or Z, and that worry is a form of guessing.

If you're worried about the performance of something, don't worry, find out.

Here's what to do:

1. Write the program

2. Performance tune it

3. Learn from the experience

What this has taught me, and I've seen it over and over, is this:

• Best practice says Don't optimize prematurely.

• Best practice says Do use lots of data structure classes, with multiple layers of abstraction, and the best big-O algorithms, "information hiding", with event-driven and notification-style architecture.

• Performance tuning reveals where the time is going, which is: Galloping generality, making mountains out of molehills, calling functions & properties with no realization of how long they take, and doing this over multiple layers using exponential time.

• Then the question is asked: What is the reason behind the best practice for the big-O algorithms, the event- and notification-driven architecture, etc. The answer comes: Well, among other things, performance.

So in a way, best practice is telling us: optimize prematurely. Get the point? It says "don't worry about performance", and it says "worry about performance", and it causes the very thing we're trying unsuccessfully not to worry about. And the more we worry about it, against our better judgement, the worse it gets.

My constructive suggestion is this: Follow steps 1, 2, and 3 above. That will teach you how to use best practice in moderation, and that will give you the best all-around design.

Answer 3

You are right, methods only exist once in memory, they're just like normal functions with an extra hidden this parameter.

And of course, only data members are taken in account for allocation, well, inheritance may introduce some extra ptrs for vptrs in the object size, but not a big deal

Answer 4

You have already got some pretty good technical advice. I want to throw in something non-technical: As the STL showed us all, doing it all in member functions might not be the best way to do this. Rather than piling up arguments, I refer to Scott Meyers' class article on the subject: How Non-Member Functions Improve Encapsulation.

Although technically there should be no problem, you still might want to review your design from a design POV.

Answer 5

These 2 bits of code are identical:

Point x;
int l=x.getLength();

int l=GetLength(x);

given that the class Point has a non-virtual method getLength(). The first invocation actually calls int getLength(Point &this), an identical signature as the one we wrote in our second example. (*)

This of course wouldn't apply if the methods you're calling are virtual, since everything would go through an extra level of indirection (something akin to the C-style int l=x->lpvtbl->getLength(x)), not to mention that instead of 2 int's for every pixel you'd actually have 3, the extra one being that pointer to the virtual table.

(*) this isn't exactly true, the "this" pointer is passed through one of the cpu registers instead of through the stack, but the mechanism could have easily worked either way.

Answer 6

I have created the same point class as you except it is a template class and all functions are inline. I expect to see performance increase not decrease by this. However, an image of size 800x600 will have 480k pixels and its memory print will be close to 4M without any color information. Not just memory but also initializing 480k object will take too much time. Therefore, I think its not a good idea in that case. However, if you use this class to transform position of an image, or use it for graphic primitives (lines, curves, circles, etc.)