alancc
alancc

Reputation: 799

How to reduce the size of an object

I am using Visual C++ to write an app. I write CMyObject class and may allocate a lot of instances of CMyObject object, so I want to reduce the size of CMyObject class.

What I can figure out to do is:

First, I can use the following code to get the accurate size used by a single instance of CMyObject object:

CMyObject Object;

//  Get the size of memory allocated for CMyObject object
int nSize = sizeof(Object);

is that correct?

Second, to reduce the size of CMyObject, I have several ideas:

(1) Change member function to static member function if it is possible, since each member function will take some spaces in the instance of CMyObject.

(2) Change virtual member function to member function if it is possible, since virtual member function may take more spaces.

(3) Eliminate unnecessary member variables to reduce spaces.

(4) Finally, if (1), (2) and (3) does not work well, then change CMyObject from class to a struct that only contains some member variables, thus will eliminate the spaces allocated for constructor and destructor of a class.

is my ideas correct?

Thanks

Upvotes: 1

Views: 2452

Answers (4)

Steve Jessop
Steve Jessop

Reputation: 279295

sizeof is correct. Technically it returns std::size_t, not int, but if your object is bigger than INT_MAX then you'd probably know about it already.

3 is correct.

1 is not correct. There is no existing C++ implementation in which member functions take up space in the object.

2 is very slightly correct. If your class (including all base classes) has no virtual members at all, then you will save roughly the size of a pointer per object. So getting rid of the last one saves space, the others don't.

4 is not correct, constructors and destructors are the same as any other member function in this respect.

As well as 3, you could try laying out the data members in a different order. The general idea is to work out where the padding will occur in your class and re-arrange the members to reduce it. The first rule of thumb is to sort them in order from the one with the greatest alignment requirement to the least, although this is implementation-dependent and anyway that's not the only way to minimize padding. Of course, this changes the order that the members are constructed and destroyed, so it may not be appropriate for your class.

Upvotes: 1

podliy16
podliy16

Reputation: 65

Only 3 is correct.

Also you can change types of variable. For example you can change int to char, if variable < 255.

Upvotes: 0

Lightness Races in Orbit
Lightness Races in Orbit

Reputation: 385204

1. Change member function to static member function if it is possible, since each member function will take some spaces in the instance of CMyObject.

Entirely incorrect. Member functions are not stored in objects. At all.

2. Change virtual member function to member function if it is possible, since virtual member function may take more spaces.

If you remove all virtual member functions in your inheritance tree, you'll prevent vtable pointers from being generated. That'll save you a few bytes, sure.

3. Eliminate unnecessary member variables to reduce spaces.

Yes, and if they're unnecessary, they should be removed anyway.

4. CMyObject from class to a struct that only contains some member variables, thus will eliminate the spaces allocated for constructor and destructor of a class.

Again, no; even if structs differed from classes in this regard (they don't), functions still aren't stored in objects. Functions are code, not data.

Upvotes: 5

Luchian Grigore
Luchian Grigore

Reputation: 258618

(1) and (2) aren't valid options. Non-virtual methods take up no space per object, virtual methods add no overhead beyond the first one defined in the inheritance hierarchy.

(3) is obviously valid.

(4), again, invalid. There's no difference, other than default access level, between class and struct.

Some other valid suggestions:

  • reordering of members (or a pragma pack). You might have padding bytes between members which might give you some overhead.
  • using smaller types (short instead of int if possible, etc.)
  • shared static data members if possible

Upvotes: 3

Related Questions