Performance Question

**Gianni Mariani** · Jul 19 '05, 05:13 PM

Re: Performance Question

Thomas Junior wrote:[color=blue]
> I always assumed C++ would have better performance than C and, when I had
> the choice, opted for C++.
>[/color]
....[color=blue]
>
> Any insight is appreciated.
>[/color]

You can write inefficient code in any language.

**Ron Natalie** · Jul 19 '05, 05:13 PM

Re: Performance Question

"Thomas Junior" <tom.junior@aut omateddesign.co m> wrote in message news:Zy%6b.5721 $BG6.577@newsre ad1.news.atl.ea rthlink.net...[color=blue]
>
> I always assumed C++ would have better performance than C and, when I had
> the choice, opted for C++.[/color]

Why? The main goal for C++ is to make it NOT SLOWER than C.
[color=blue]
> My question is not application-specific, but general: Is C a more efficient
> compiler than C++, offering better performance? Do the extra features of C++
> slow down the execution of the final product?[/color]

C is not in general any more efficient. The C++ schemers took great pains to
not make things slower to do in C++ than they are in C. A lot of the odd features
of C++ reflect this. The idea is to not insert any performance penalties unless you
need the feature (for example, the fact that certain operations require polymorphic
classes, or that things aren't "virutal" by default).

**Julián Albo** · Jul 19 '05, 05:13 PM

Re: Performance Question

Thomas Junior escribió:
[color=blue]
> "KDE came first and came earlier to a mature state but C++ makes Qt andMICO
> particularly inefficient for sophisticated applications. This was partially
> corrected in version 2.0 and the coming 2.1."[/color]

Nonsense. If C++ was the cause for inefficience, and considering that
KDE has not switched langauge, no new version can have corrected it,
partially or not.

Regards.

**Agent Mulder** · Jul 19 '05, 05:13 PM

Re: Performance Question

<>
I always assumed C++ would have better performance than C and, when I had
the choice, opted for C++.

Today, however, I was researching writing components for Linux and came
across this statement:

"KDE came first and came earlier to a mature state but C++ makes Qt and MICO
particularly inefficient for sophisticated applications. This was partially
corrected in version 2.0 and the coming 2.1."

The comparison was to GNOME, which is written in C.

My question is not application-specific, but general: Is C a more efficient
compiler than C++, offering better performance? Do the extra features of C++
slow down the execution of the final product?
</>

Virtual functions do slow down your program.
But otherwise your cpu might run hot :-). Don't
bother about it. Someone else told you that you
can write bad code in any language. Some even
support it. C++ doens't.

-X

**Ralph Peterson** · Jul 19 '05, 05:14 PM

Re: Performance Question

Thomas Junior wrote:
[color=blue]
>
> I always assumed C++ would have better performance than C and, when I had
> the choice, opted for C++.
>
> [snip]
>
> My question is not application-specific, but general: Is C a more
> efficient compiler than C++, offering better performance? Do the extra
> features of C++ slow down the execution of the final product?[/color]

C is (almost) a subset of C++. Whether a program that uses only C constructs
is compiled via a C or C++ compiler should have no impact on the execution
speed of the program.

C++ features that have no equivalent in C cannot be compared. Some people
say that virtual functions slow programs down. But what's the alternative?
A switch-statement that implements the same behaviour would probably
execute slower.

Some C++ features like inline methods and templates make it actually
possible to write faster programs than in C.

But you have to know your tools. It's easy to write slow programs in C++. I
ported a poorly programmed C++ program to Java. The Java version executes
much (!) faster than the original C++ code (and the Java version needs much
more memory too).

Best regards
Ralph

**llewelly** · Jul 19 '05, 05:14 PM

Re: Performance Question

"Agent Mulder" <mbmulder_remov e_this_@home.nl > writes:
[snip][color=blue]
> Virtual functions do slow down your program.[/color]
[snip]

Nonsense. My experience optimizing real world C++ is that virtual
hardly ever matters. If you *need* virtual, no C equivalent will
be faster. If you don't need it (which is much of the time), there
is usually a design reason (independent of performance) why you
should not be using it in the first place.

**Thomas Junior** · Jul 19 '05, 05:14 PM

Re: Performance Question -- Thanks!

Thanks for the information, everybody. I was surprised by the statement in
the article, and wondered if there was something going on that I didn't know
about.

I have used virtual functions only for my Serial Communication class
(different chipsets), and did not notice an impact on speed. Of course, I
never bothered to clock it.

One person said to me this morning that KDE and GNOME are "pigs" due to "bad
programming." I asked him to elaborate on how it is programmed badly, but he
didn't. Maybe I'll download the source code for KDE and try and see if/where
they're sloppy. I am surprised by the resources it hogs up.

Thanks again for setting my mind at ease, everybody.

Tom Junior
"Ralph Peterson" <ralph.peterson @gmx.net> wrote in message
news:bji9ai$jdv ii$1@news.hanse net.net...[color=blue]
> Thomas Junior wrote:
>[color=green]
> >
> > I always assumed C++ would have better performance than C and, when I[/color][/color]
had[color=blue][color=green]
> > the choice, opted for C++.
> >
> > [snip]
> >
> > My question is not application-specific, but general: Is C a more
> > efficient compiler than C++, offering better performance? Do the extra
> > features of C++ slow down the execution of the final product?[/color]
>
> C is (almost) a subset of C++. Whether a program that uses only C[/color]
constructs[color=blue]
> is compiled via a C or C++ compiler should have no impact on the execution
> speed of the program.
>
> C++ features that have no equivalent in C cannot be compared. Some people
> say that virtual functions slow programs down. But what's the alternative?
> A switch-statement that implements the same behaviour would probably
> execute slower.
>
> Some C++ features like inline methods and templates make it actually
> possible to write faster programs than in C.
>
> But you have to know your tools. It's easy to write slow programs in C++.[/color]
I[color=blue]
> ported a poorly programmed C++ program to Java. The Java version executes
> much (!) faster than the original C++ code (and the Java version needs[/color]
much[color=blue]
> more memory too).
>
> Best regards
> Ralph[/color]

**Peter van Merkerk** · Jul 19 '05, 05:16 PM

Re: Performance Question -- Thanks!

> Thanks for the information, everybody. I was surprised by the
statement in[color=blue]
> the article, and wondered if there was something going on that I[/color]
didn't know[color=blue]
> about.
>
> I have used virtual functions only for my Serial Communication class
> (different chipsets), and did not notice an impact on speed. Of[/color]
course, I[color=blue]
> never bothered to clock it.[/color]

When doing I/O, the I/O itself is most likely the bottleneck. No amount
of optimization will help here as the time to transmit one byte over a
serial line probably takes much, much more time than a virtual function
call. Even if you would use a slower language (e.g. Java, Python), you
probably won't notice the difference. If you have a performance problem
you should always profile first to pinpoint the bottleneck. If the
application is I/O bound it is usually a good idea to look for a ways to
more efficiently use the I/O subsystem (e.g. sending large chunks of
data at once instead of one byte at a time or using non-blocking I/O).
[color=blue]
> One person said to me this morning that KDE and GNOME are "pigs" due[/color]
to "bad[color=blue]
> programming." I asked him to elaborate on how it is programmed badly,[/color]
but he[color=blue]
> didn't. Maybe I'll download the source code for KDE and try and see[/color]
if/where[color=blue]
> they're sloppy. I am surprised by the resources it hogs up.[/color]

When developing something like KDE and GNOME there are other concerns
than performance as well, like for example flexibility, configurability ,
extendabilty, maintainability ...etc. Sometimes those issues conflict
with performance, and considering the ever increase power hardware it
might make sense to favor those concerns over performance. No doubt
those software packages carry also a fair share of historic bagage with
them.

--
Peter van Merkerk
peter.van.merke rk(at)dse.nl

Performance Question

Performance Question

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment