What's better, Big classes or Small

[ManicQin]

Let's ignore for a minute design decisions , readability and any other
of those parameters , In the most raw form of c++ (purely efficiency
if you want)
what is better, bloating up a classes or breaking them up to small
classes?
(and again pure efficiency of the compiler)
Thanks

[Nick Keighley]

On 27 Aug, 10:35, ManicQin <[e-mail]:

Let's ignore for a minute design decisions , readability and any other
of those parameters , In the most raw form of c++ (purely efficiency
if you want)
what is better, bloating up a classes or breaking them up to small
classes?
(and again pure efficiency of the compiler)

skip the compiler and write it directly in machine code

--
Nick Keighley

[ManicQin]

Nick Keighley wrote:

On 27 Aug, 10:35, ManicQin <[e-mail]:

Let's ignore for a minute design decisions , readability and any other
of those parameters , In the most raw form of c++ (purely efficiency
if you want)
what is better, bloating up a classes or breaking them up to small
classes?
(and again pure efficiency of the compiler)

skip the compiler and write it directly in machine code

--
Nick Keighley

01000001 01110011 01110011 00100000 01001000 01101111 01101100
01100101 ...

[Matthias Buelow]

ManicQin wrote:

Let's ignore for a minute design decisions , readability and any other
of those parameters , In the most raw form of c++ (purely efficiency
if you want)
what is better, bloating up a classes or breaking them up to small
classes?
(and again pure efficiency of the compiler)

The biggest factor in execution speed of a large program are design
decisions and readability. Anything else is something the profiler will
tell you about.

[Juha Nieminen]

ManicQin wrote:

Let's ignore for a minute design decisions , readability and any other
of those parameters , In the most raw form of c++ (purely efficiency
if you want)
what is better, bloating up a classes or breaking them up to small
classes?
(and again pure efficiency of the compiler)

What do you mean by "pure efficiency of the compiler"? How fast the
compiler can compile your source files?

[Pascal J. Bourguignon]

ManicQin <Ma******@gmail.comwrites:

Let's ignore for a minute design decisions , readability and any other
of those parameters , In the most raw form of c++ (purely efficiency
if you want)
what is better, bloating up a classes or breaking them up to small
classes?
(and again pure efficiency of the compiler)

Neither big or small. Medium sized classes.

The point is that both human programmers, and modern processors are
sized to handle efficiently in short term memory (L1-cache) a medium
number of items. That is, betweeen 5 and 9, 7 on average.

That's the average number of data member a object shall have,
(multiply by 2 to 4 times for the number of methods).

Of course, you may have exceptions, with one or zero data, or with 40
data fields, but you would have to give a very strong reason why not
store the 40 data into a dictionnary, and why not remove the class
with one data member and using directly the data.
Otherwise, for the question of efficiency of the compiler, by the time
your program is termined (and this will be farther in the future the
more you think about performace in these terms), the hardware will
have evolved in such a way and magnitude, that any step you could have
made toward that efficiency would be totally irrelevant (and possibly
counter productive).

--
__Pascal Bourguignon__

[Paavo Helde]

ManicQin <Ma******@gmail.comkirjutas:

Let's ignore for a minute design decisions , readability and any other
of those parameters , In the most raw form of c++ (purely efficiency
if you want)
what is better, bloating up a classes or breaking them up to small
classes?
(and again pure efficiency of the compiler)

You can bloat up classes either by adding a lot of member functions, or
by adding a lot of data members.

The number of member functions should not have any impact on program
speed. If they are virtual, the vtable fo the class gets bigger, but a
number of vtables for split-up objects would make up the same, so there
is no difference. For non-virtual functions there should be no difference
wahtsoever.

The number of data members in the class should not make any difference as
well. If they are in the separate classes the total amount of memory
would be the same. When processing arrays of objects, smaller classes may
have better cache locality. OTOH, if your processing would involve
accessing different classes/arrays all the time, this might not be a win.

The solution: design your classes to be most maintainable. If there is a
performance issue, profile the code, find the bottlenecks and fix them.
Serious bottlenecks are caused by wrong algorithms, not by the class
layout.

hth
Paavo