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; uint y; as data, and have defined virtually everything that math can do to a point as methods. Some of those methods might be huge. (copy-)constructors do nothing more than initializing the two data members.

class Point
{
   int mx; int my;
   Point(int x, int y):mx(x),my(y){};
   Point(const Point& other):mx(other.x),my(other.y){};
 // .... HUGE number of methods....
};

Now. I load a big image and create a Point for every pixel, stuff em into a vector and use them. (say, all methods get called once) This is only meant as a stupid example!

Would it be any slower than the same class without the methods but with a lot of utility functions? I am not talking about virtual functions in any way!

My Motivation for this: I often find myself writing nice and relatively powerful classes, but when I have to initialize/use a ton of them like in the example above, I get nervous. I think I shouldn't.

what I think I know is:

1. Methods exist only once in memory. (optimizations aside)
2. Allocation only takes place for the data members, and they are the only thing copied.

So it shouldn't matter. Am I missing something?

Answer 1

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 2

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 3

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.