Performance Question

[Thomas Junior]

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?

Any insight is appreciated.

Thanks!
--

Tom Junior
to********@automateddesign.com

Automated Design Corporation
P: [phone] F: [phone]

[Gianni Mariani]

Thomas Junior wrote:

I always assumed C++ would have better performance than C and, when I had
the choice, opted for C++.
....
Any insight is appreciated.

You can write inefficient code in any language.

[Ron Natalie]

"Thomas Junior" <to********@automateddesign.com> wrote in message news:Zy****************@newsread1.news.atl.earthli nk.net...

I always assumed C++ would have better performance than C and, when I had
the choice, opted for C++.
Why? The main goal for C++ is to make it NOT SLOWER than 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?

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]

Thomas Junior escribió:

"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."

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]

<>
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]

Thomas Junior wrote:

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?

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]

"Agent Mulder" <mb*******************@home.nl> writes:
[snip]

Virtual functions do slow down your program.

[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]

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" <ra************@gmx.net> wrote in message
news:bj************@news.hansenet.net...

Thomas Junior wrote:

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?
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

[Peter van Merkerk]

> 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.
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).
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.

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.merkerk(at)dse.nl