Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Ask for book for efficient coding in C

Reply
Thread Tools

Ask for book for efficient coding in C

 
 
MBALOVER
Guest
Posts: n/a
 
      02-20-2010
Hi all,

Do you know what book that discusses what we should and should not do
in C programming? It is not a book teaching about syntax, etc. but a
book teaches us the experience to optimize our code.

For example, I read somewhere that we should avoid function calls to
make the program run fast. Calling (and returning from) a function is
time-consuming, and not because the content of the function takes time
to execute just getting into the function, and back out of it, uses
processor time.

I want to find some experiences like this.

Do you know any book discussing this?

Thank you.





 
Reply With Quote
 
 
 
 
MBALOVER
Guest
Posts: n/a
 
      02-20-2010
Thanks Richard,

I am reading the web site and it is really helpful.

Thanks a lot.


On Feb 20, 6:07*pm, Richard Heathfield <(E-Mail Removed)> wrote:
> MBALOVER wrote:
> > Hi all,

>
> > Do you know what book that discusses what we should and should not do
> > in C programming? It is not a book teaching about syntax, etc. but a
> > book teaches us the experience to optimize our code.

>
> > For example, I read somewhere that we should avoid function calls to
> > make the program run fast. *Calling (and returning from) a function is
> > time-consuming, and not because the content of the function takes time
> > to execute just getting into the function, and back out of it, uses
> > processor time.

>
> > I want to find some experiences like this.

>
> > Do you know any book discussing this?

>
> I do, but I'm not going to tell you what it is - for two reasons.
> Firstly, because the book I have in mind discusses lots of other things
> as well; it's not dedicated solely to the subject of optimisation. And
> the second reason is that you can get most or maybe all of what it has
> to say, from the Web:
>
> http://leto.net/docs/C-optimization.php
>
> Not sure if that's the owner's link, but it looks good.
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within


 
Reply With Quote
 
 
 
 
Hamiral
Guest
Posts: n/a
 
      02-21-2010
Richard Heathfield wrote:
> http://leto.net/docs/C-optimization.php
>
> Not sure if that's the owner's link, but it looks good.
>


To answer to the OP :
"Part of the clarity is making hunks of code into functions when
appropriate. The cost of a function call is extremely small on modern
machines, so optimization is NOT a valid excuse for writing ten-page
functions."
This is an extract from the website you gave, and every programmmer (any
language) should stick to that.

Ham
 
Reply With Quote
 
Anand Hariharan
Guest
Posts: n/a
 
      02-21-2010
On Feb 20, 5:47*pm, MBALOVER <(E-Mail Removed)> wrote:
> Thanks Richard,
>
> I am reading the web site and it is really helpful.
>
> Thanks a lot.
>
> On Feb 20, 6:07 pm, Richard Heathfield <(E-Mail Removed)> wrote:
>
>
>
> > MBALOVER wrote:
> >


Please read up on usenet etiquette; in particular, please do not top-
post, quote signatures.


> > > For example, I read somewhere that we should avoid function calls to
> > > make the program run fast. *Calling (and returning from) a function is
> > > time-consuming, and not because the content of the function takes time
> > > to execute just getting into the function, and back out of it, uses
> > > processor time.

>



Depending upon what "avoid function calls" means, that is very bad
advice (results in spaghetti code) or if it is taken to mean inlining
(implementations provide them as optimisation options), may or may not
lead to faster programs:

http://www.parashift.com/c++-faq-lit...s.html#faq-9.3

(Note that the link is about a C++ keyword, but the specific answer is
meaningful for C as well.)

- Anand
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      02-21-2010
On Feb 21, 6:53*am, Hamiral <(E-Mail Removed)> wrote:
>
> "Part of the clarity is making hunks of code into functions when
> appropriate. The cost of a function call is extremely small on modern
> machines, so optimization is NOT a valid excuse for writing ten-page
> functions."
>

Normally you're right. However there might be situations where the
program doesn't have a few tight inner loops (which are usually the
only things worth optimising). In this case, the function call
overhead may be significant.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      02-21-2010
Malcolm McLean <(E-Mail Removed)> writes:

> On Feb 21, 6:53 am, Hamiral <(E-Mail Removed)> wrote:
>>
>> "Part of the clarity is making hunks of code into functions when
>> appropriate. The cost of a function call is extremely small on
>> modern machines, so optimization is NOT a valid excuse for writing
>> ten-page functions."
>>

> Normally you're right. However there might be situations where the
> program doesn't have a few tight inner loops (which are usually the
> only things worth optimising). In this case, the function call
> overhead may be significant.


Did you mean to say that function call overhead may be significant in
the case of programs having inner loops?

One side benefit of keeping functions relatively small is that it
becomes easier for the compiler to inline calls to such functions,
rather than massive monolithic ones. However, as in everything else,
you can take this strategy too far.


 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      02-21-2010
On Feb 21, 10:30*am, santosh <(E-Mail Removed)> wrote:
>
> Did you mean to say that function call overhead may be significant in
> the case of programs having inner loops?
>

Every program that takes a long time to execute will perform a large
number of operations, which means it must either have one big loop
which means most of the code is executed many many times, or several
inner loops, such that the inner loops are executed many many times,
but the rest of the code only a few times.
The second situation is by far the most common, but the first is
possible. If the first, you may find that breaking the program down
into functions has an appreciable effect on execution time. In the
second case, only adding or removing function calls from the inner
loops will have any appreciable effect.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      02-21-2010
On 2/20/2010 6:02 PM, MBALOVER wrote:
> Hi all,
>
> Do you know what book that discusses what we should and should not do
> in C programming? It is not a book teaching about syntax, etc. but a
> book teaches us the experience to optimize our code.
>
> For example, I read somewhere that we should avoid function calls to
> make the program run fast. Calling (and returning from) a function is
> time-consuming, and not because the content of the function takes time
> to execute just getting into the function, and back out of it, uses
> processor time.
>
> I want to find some experiences like this.
>
> Do you know any book discussing this?


If you find such a book, burn it.

Don't burn the author, not yet, because it's just barely
possible he might be saying something useful. However, your
understanding of C -- of programming in general, I'd guess --
is not yet advanced enough to let you distinguish folly from
useful advice.

For example, the advice that you "read somewhere" is folly,
at least in the form you've repeated it. This means either that
the writer was a fool, or (more likely) that you've omitted the
important context that might -- might! -- make the advice not
be foolhardy. Why would you leave such things out? Because,
probably, you're not yet equipped to recognize their importance.
Advice is situational; advice that is good in one situation may
be terrible in another, and you cannot use the advice wisely
until you've learned to recognize the situations.

Here's my bit of advice: First, the most important thing
about a program is that it does what it is supposed to -- if
it fails to do that, or does it wrong, the speed seldom matters.
So, concentrate first on getting your code to work, because a
fast failure is of no use to anybody.

Second, once the code is working you may -- may! -- find
that it's too slow for your purposes. If so, you must *measure*
its behavior to discover where the time is going. You must also
realize that a lot of what you measure will be specific to the
particular compiler and machine and so on that you're using, and
may not be transferable to other compilers, other machines. Make
changes as your *measurements* suggest, and *measure* the speedup;
if a change doesn't produce a speedup, rescind it. Once the
program is "fast enough," stop!

I'll leave you with Michael Jackson's oft-quoted advice:

FIRST LAW OF PROGRAM OPTIMIZATION: Don't do it.

SECOND LAW OF PROGRAM OPTIMIZATION (for experts only):
Don't do it yet.

He's smarter than both of us put together; heed his message.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      02-21-2010
On 2/21/2010 10:53 AM, Richard Heathfield wrote:
> Eric Sosman wrote:
>> On 2/20/2010 6:02 PM, MBALOVER wrote:
>>> Hi all,
>>>
>>> Do you know what book that discusses what we should and should not do
>>> in C programming? It is not a book teaching about syntax, etc. but a
>>> book teaches us the experience to optimize our code.
>>>
>>> For example, I read somewhere that we should avoid function calls to
>>> make the program run fast. Calling (and returning from) a function is
>>> time-consuming, and not because the content of the function takes time
>>> to execute just getting into the function, and back out of it, uses
>>> processor time.
>>>
>>> I want to find some experiences like this.
>>>
>>> Do you know any book discussing this?

>>
>> If you find such a book, burn it.

>
> I cannot imagine that you are advocating burning books on optimisation.
> Presumably you only intend to advocate burning /bad/ books on optimisation?


Not even that: My advice was directed specifically to the O.P.,
a person to whom Jackson's Second Law does not yet apply. At his
present stage of development, optimization books good or bad can
only do him harm.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      02-24-2010
MBALOVER <(E-Mail Removed)> wrote:

> I am reading the web site and it is really helpful.


Be aware that at your current level of proficiency (i.e., given that you
have to ask these questions in the first place!), the most important
section by far for you is the one titled "GOTCHAS".

Richard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[ask] coding in visual studio 2008 without .NET doniking C++ 0 10-21-2008 02:53 PM
Ask for book recommendation on component programming shuisheng C++ 1 03-12-2007 01:02 PM
general coding issues - coding style... calmar Python 11 02-21-2006 10:36 AM
Help:efficient FSM coding msd VHDL 1 02-22-2005 02:59 PM
Ask for book information John C++ 2 11-18-2004 05:41 PM



Advertisments