Re: is C necessarily faster than C++

tbrannon <tbrannon@mars.mars.eecs.lehigh.edu> wrote:
>This guy in my lab keeps refusing to use C++ in our program intended
>to simulate somatosensory neural circuits because he says it is slower
>than C. My (uninformed) response was that most of what you see as
>overhead (ie, message routing, value accessing, type checking) is
>optimized away at compile-time.
>
>Any pointers to more empirical studies?


Well, in principle the only factor that could significantly slow down
C++ relative to C is the overhead attributed to virtual functions.
However, in practice, because every complex object has both a constructor
and a destructor, there is an additional function overhead cost.


It is said that these can be inlined, but not all compilers do so,
and it's not always possible either. More importantly, constructing
and destructing local complex objects takes a lot of malloc-ing and
free-ing. Experienced C programmers having to write efficient code
usually avoid many calls to malloc by fooling around with pointers
and keeping track of allocation themselves.


Take a C program that manipulates strings. Experienced C programmers
will keep track of what string resides where, avoiding unneccesary
copying. Now using a good string library in C++ relieves you of the
burden of keeping track of your memory, but it adds the overhead of
constructing and destructing them. In a way it's like the shortcuts
one can take using assembler. Using assembly language can give you
a certain performance advantage, but you have to pay more attention
to the dirty details.


Hope this helps,


Jan
--

Return to the comp.compilers page.
Search the comp.compilers archives again.