By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,006 Members | 1,154 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,006 IT Pros & Developers. It's quick & easy.

New wikibook about efficient C++

P: n/a
Hello,
I just completed writing an online book about developing efficient
software using the C++ language.
You can find it here: http://en.wikibooks.org/wiki/Optimizing_C%2B%2B
It is a wiki, that is everyone can change it or only add critical
comments to the pages.
Everyone is invited to improve it. But before applying major changes,
please read these guidelines:
http://en.wikibooks.org/wiki/Optimiz...es_for_editors

--
Carlo Milanesi
http://digilander.libero.it/carlmila
Jun 27 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Carlo Milanesi wrote:
I just completed writing an online book about developing efficient
software using the C++ language.
The text contains mostly irrelevant and sometimes erroneous
suggestions. Most of the suggested micro-optimizations will usually not
make your program any faster at all and thus are completely irrelevant.
Some examples:

"Don't check that a pointer is non-null before calling delete on it."

While it's true that you don't have to check for null before deleting,
speedwise that's mostly irrelevant. In most systems with most compilers
the 'delete' itself is a rather heavy operation, and the extra clock
cycles added by the conditional will not make the program relevantly
slower. It might become more relevant if you have a super-fast
specialized memory allocator where a 'delete' takes next to nothing of
time, and humongous amounts of objects are deleted in a short time.
However, in normal situations it's irrelevant.

"Declare const every member function that does not change the state of
the object on which it is applied."

Mostly irrelevant speedwise.

"Instead of writing a for loop over an STL container, use an STL
algorithm with a function-object or a lambda expression"

Why is that any faster than the for loop? (In fact, it might even be
slower if, for whatever reason, the compiler is unable to inline the
lambda function.)

"Though, every time a function containing substantial code is inlined,
the machine code is duplicated, and therefore the total size of the
program is increased, causing a general slowing down."

Mostly not true. There is no necessary correlation between code size
and speed. In fact, sometimes a longer piece of code may perform faster
than a shorter one (for example loop unrolling performed by the compiler
sometimes produces faster code, even in modern processors).

"Among non-tiny functions, only the performance critical ones are to be
declared inline at the optimization stage."

The main reason to decide whether to declare a larger function
'inline' or not is not about speed. The compiler has heuristics for this
and will not inline the function if it estimates that it would be
counter-productive. The main reason to use or avoid 'inline' has more to
do with the quality of the source code.

"In addition, every virtual member function occupies some more space"

Irrelevant, unless you are developing for an embedded system with a
*very* small amount of memory.

"Do not null a pointer after having called the delete operator on it, if
you are sure that this pointer will no more be used."

Irrelevant. The 'delete' itself will usually be so slow that the
additional assignment won't change the anything.

"Garbage collection, that is automatic reclamation of unreferenced
memory, provides the ease to forget about memory deallocation, and
prevents memory leaks. Such feature is not provided by the standard
library, but is provided by non-standard libraries. Though, such memory
management technique causes a performance worse than explicit
deallocation (that is when the delete operator is explicitly called)."

This is simply not true. In fact, GC can be made faster than explicit
deallocation, at least compared to the default memory allocator used by
most C++ compilers.

"To perform input/output operations, instead of calling the standard
library functions, call directly the operating system primitives."

Dubious advice. The general (and portable) advice for fast I/O is to
use fread() and fwrite() for large blocks of data (the C++ equivalents
may actually be equally fast, if called rarely). If very small amounts
of data (such as characters) need to be read or written individually,
use the correspondent C I/O functions.

In places where I/O speed is irrelevant, this advice is
counter-productive.

"Look-up table"

This was relevant in the early 90's. Nowadays it's less evident. With
modern CPUs sometimes using a lookup table instead of a seemingly "slow"
function might actually be slower, depending on a ton of factors.

"Instead of doing case-insensitive comparisons between a strings,
transform all the letters to uppercase (or to lowercase), and then do
case-sensitive comparisons."

Yeah, because converting the string does not take time?

Jun 27 '08 #2

P: n/a
Juha Nieminen wrote:
"Instead of writing a for loop over an STL container, use an STL
algorithm with a function-object or a lambda expression"

Why is that any faster than the for loop? (In fact, it might even be
slower if, for whatever reason, the compiler is unable to inline the
lambda function.)
Probably based on the fact that the algorithm can take advantage of
implementation specific knowledge whereas your for loop can't, or at
least shouldn't.

I don't know that any implementation does this though.
Jun 27 '08 #3

P: n/a
On 9 Jun., 19:08, Carlo Milanesi <carlo.milanesi.no.s...@libero.it>
wrote:
Juha Nieminen ha scritto:
Carlo Milanesi wrote:
I just completed writing an online book about developing efficient
software using the C++ language.
* The text contains mostly irrelevant and sometimes erroneous
suggestions. Most of the suggested micro-optimizations will usually not
make your program any faster at all and thus are completely irrelevant.
* Some examples:

You look too harsh! The book contains 98 advices, your critiques regard
only 11 of them. Are you sure that there others are mostly completely
irrelevant to a non-expert programmer?
I do not find that your recommendations are to bad. While I mostly
agre with Juha, much of the advice you give is good even if is not
related to (program) performance. The first advice of not checking a
pointer for null before deleting it, for example, is very good advice
if you wish to increase programmer performance ;-)

The worst advice I saw (and I only read Juhas post) was to avoid the
standard library for I/O. And yet, today it is unfortunately quite
relevant should your program have the bottleneck in formatted I/O.

/Peter
Jun 27 '08 #4

P: n/a
On Jun 9, 7:08 pm, Carlo Milanesi <carlo.milanesi.no.s...@libero.it>
wrote:
Juha Nieminen ha scritto:
[...]
"Garbage collection, that is automatic reclamation of
unreferenced memory, provides the ease to forget about
memory deallocation, and prevents memory leaks. Such feature
is not provided by the standard library, but is provided by
non-standard libraries. Though, such memory management
technique causes a performance worse than explicit
deallocation (that is when the delete operator is explicitly
called)."
This is simply not true. In fact, GC can be made faster than
explicit deallocation, at least compared to the default
memory allocator used by most C++ compilers.
Then why not everyone is using it, and not every guru is
recommending it?
Many do (Stroustrup, for example). And the guru's that
recommend against it don't do so on performance grounds. The
one thing I think all gurus agree on is that performancewise, it
all depends. There are programs where garbage collection will
speed the program up, and there are programs which will run
slower with it. And that in all cases, it depends on the actual
implementation of the manual management or the garbage
collection.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #5

P: n/a
peter koch ha scritto:
>>Carlo Milanesi wrote:
I just completed writing an online book about developing efficient
software using the C++ language.
The first advice of not checking a
pointer for null before deleting it, for example, is very good advice
if you wish to increase programmer performance ;-)
I have already removed it, as the book is only about program performance.
The worst advice I saw (and I only read Juhas post) was to avoid the
standard library for I/O. And yet, today it is unfortunately quite
relevant should your program have the bottleneck in formatted I/O.
In fact, there is not substantial difference between the performance of
"fread/fwrite" and that of the OS API. But I found noticeable difference
with using the "fstream" family of classes.

For example, the following code:
ifs.seekg(0);
ifs.read(buf, sizeof buf);
int rc = ifs.gcount();

results to be much slower than the following:
rewind(fp);
int rc = fread(buf, 1, sizeof buf, fp);

at least when "buf" if smaller then 1MB.
So I am going to change the advice in "Use stdio instead of fstream for
binary I/O".

--
Carlo Milanesi
http://digilander.libero.it/carlmila
Jun 27 '08 #6

P: n/a
Bo Persson ha scritto:
Carlo Milanesi wrote:
>>"Garbage collection, that is automatic reclamation of unreferenced
memory, provides the ease to forget about memory deallocation, and
prevents memory leaks. Such feature is not provided by the standard
library, but is provided by non-standard libraries. Though, such
memory management technique causes a performance worse than
explicit deallocation (that is when the delete operator is
explicitly called)." This is simply not true. In fact, GC can be
made faster than
explicit deallocation, at least compared to the default memory
allocator used by most C++ compilers.
Then why not everyone is using it, and not every guru is
recommending it? I have never measured GC performance. Are there
any research papers aroun about its performance in C++ projects?

As usual, it depends.

Some "gurus" actually do use GC when there is an advantage. This one,
for example:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Boehm is a GC evangelist and so his opinions are biased :)
Anyway, I understood that GC is competitive when you are allocating
small objects, i.e. with an average size of less then 64 bytes, and it
is better only if the average allocated object size is even smaller, but
it is worse with larger allocations.
The wikibook recommends to minimize allocations in bottlenecks, by using
"reserve" or object pools. That tends to increase the average object size.
In addition, the wikibook does not say "never use GC", but "only if you
can prove its expediency for the specific case.".
I'll improve a bit the rationale for that.

--
Carlo Milanesi
http://digilander.libero.it/carlmila
Jun 27 '08 #7

P: n/a
Carlo Milanesi wrote:
Bo Persson ha scritto:
>Carlo Milanesi wrote:
>>>"Garbage collection, that is automatic reclamation of
unreferenced memory, provides the ease to forget about memory
deallocation, and prevents memory leaks. Such feature is not
provided by the standard library, but is provided by
non-standard libraries. Though, such memory management technique
causes a performance worse than explicit deallocation (that is
when the delete operator is explicitly called)." This is simply
not true. In fact, GC can be made faster than
explicit deallocation, at least compared to the default memory
allocator used by most C++ compilers.
Then why not everyone is using it, and not every guru is
recommending it? I have never measured GC performance. Are there
any research papers aroun about its performance in C++ projects?

As usual, it depends.

Some "gurus" actually do use GC when there is an advantage. This
one, for example:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Boehm is a GC evangelist and so his opinions are biased :)
You mean that he knows what he is talking about? :-)
Anyway, I understood that GC is competitive when you are allocating
small objects, i.e. with an average size of less then 64 bytes, and
it is better only if the average allocated object size is even
smaller, but it is worse with larger allocations.
The wikibook recommends to minimize allocations in bottlenecks, by
using "reserve" or object pools. That tends to increase the average
object size. In addition, the wikibook does not say "never use GC",
but "only if you can prove its expediency for the specific case.".
I'll improve a bit the rationale for that.
Sounds good.
Bo Persson
Jun 27 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.