Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C perfomance

Reply
Thread Tools

C perfomance

 
 
Papadopoulos Giannis
Guest
Posts: n/a
 
      01-29-2004
a) pre vs post increment/decrement

I have read somewhere that:

“Prefer pre-increment and -decrement to postfix operators. Postfix
operators (i++) copy the existing value to a temporary object, increment
the internal value, and then return the temporary. Prefix operators
(++i) increment the value and return a reference to it. With objects
such as iterators, creating temporary copies is expensive compared to
built-in ints.”

A modern compiler wouldn’t make the optimization, so

i++;

and

++i;

would give the same instructions?


b) I find that realloc() calls sometimes take more time to complete than
malloc() calls. Is this the general case?


c) Why do some people declare all the variables at the start of each
function? And I mean ALL variables, including those that are nested in
deep fors and ifs... I don’t see any obvious performance gains - unless
they do it to remember what they are using...

 
Reply With Quote
 
 
 
 
Papadopoulos Giannis
Guest
Posts: n/a
 
      01-29-2004
Bruno Desthuilliers wrote:
> Papadopoulos Giannis wrote:
> (snip)
>
>>
>> c) Why do some people declare all the variables at the start of each
>> function? And I mean ALL variables, including those that are nested in
>> deep fors and ifs...

>
>
> Could it be possible that some people don't know that they can declare
> variables at the start of each *block* ?-)
>
> Bruno
>

Maybe.. But I find it often and I wonder...

 
Reply With Quote
 
 
 
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      01-29-2004
Papadopoulos Giannis wrote:
(snip)
>
> c) Why do some people declare all the variables at the start of each
> function? And I mean ALL variables, including those that are nested in
> deep fors and ifs...


Could it be possible that some people don't know that they can declare
variables at the start of each *block* ?-)

Bruno

 
Reply With Quote
 
Christian Bau
Guest
Posts: n/a
 
      01-29-2004
In article <bvbuvg$2pub$(E-Mail Removed)>,
Papadopoulos Giannis <(E-Mail Removed)> wrote:

> a) pre vs post increment/decrement
>
> I have read somewhere that:
>
> ³Prefer pre-increment and -decrement to postfix operators. Postfix
> operators (i++) copy the existing value to a temporary object, increment
> the internal value, and then return the temporary. Prefix operators
> (++i) increment the value and return a reference to it. With objects
> such as iterators, creating temporary copies is expensive compared to
> built-in ints.²


I bet you didn't read that in a book about C.

> b) I find that realloc() calls sometimes take more time to complete than
> malloc() calls. Is this the general case?


> c) Why do some people declare all the variables at the start of each
> function? And I mean ALL variables, including those that are nested in
> deep fors and ifs... I don¹t see any obvious performance gains - unless
> they do it to remember what they are using...


You worry too much about performance, and you worry too much about the
wrong kind of performance. First try to write code that is bug-free and
readable. That is the most important thing.

If there is need to make your code faster: First measure. Get yourself a
profiler, learn how to use it, learn how to interpret the numbers. Then
before trying to figure out how to make an operation faster that you do
a million times, figure out how to do it only 100,000 times or 1000
times. That's how you make a program fast.
 
Reply With Quote
 
E. Robert Tisdale
Guest
Posts: n/a
 
      01-29-2004
Papadopoulos Giannis wrote:

> a) pre vs post increment/decrement
>
> I have read somewhere that:
>
> “Prefer pre-increment and -decrement to postfix operators. Postfix
> operators (i++) copy the existing value to a temporary object,
> increment the internal value, and then return the temporary.
> Prefix operators (++i) increment the value
> and return a reference to it. With objects such as iterators,
> creating temporary copies is expensive compared to built-in ints.”


This must be a reference to
overloaded increment and decrement operators in C++.

Favoring pre-decrement/increment over post decrement/increment
operators is a good habit for C programmers who must also
write C++ programs. Otherwise, it is a matter of style.

> A modern compiler wouldn’t make the optimization, so
>
> i++;
>
> and
>
> ++i;
>
> would give the same instructions?


Yes.

> b) I find that realloc() calls sometimes take more time to complete
> than malloc() calls. Is this the general case?


Typically, the difference is hard to measure except in contrived cases.

> c) Why do some people declare all the variables
> at the start of each function? And I mean *all* variables
> including those that are nested in deep for's and ifs...
> I don’t see any obvious performance gains -
> unless they do it to remember what they are using...


1. Some C programs are translations of Fortran programs.
2. Some C programs are written by Fortran programmers.
3. Early versions of C (before C 89) required this
according to Brian W. Kernighan and Dennis M. Ritchie
in "The C Programming Language",
Chapter 1: A Tutorial Introduction,
Section 2: Variables and Arithmetic, page 8:
"In C, /all/ variables must be declared before use, usually
at the beginning of a function before any executable statements."





 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      01-29-2004
On Thu, 29 Jan 2004 23:45:25 +0200, in comp.lang.c , Papadopoulos
Giannis <(E-Mail Removed)> wrote:

>a) pre vs post increment/decrement
>
>I have read somewhere that:
>
>“Prefer pre-increment and -decrement to postfix operators.


Yes, this is an old chestnut. I can find nothing to support it
nowadays, tho ICBW.
>i++;
>and
>++i;
>would give the same instructions?


AFAIK yes. Try it and see.

>b) I find that realloc() calls sometimes take more time to complete than
>malloc() calls. Is this the general case?


The standard doesn't say.

>c) Why do some people declare all the variables at the start of each
>function?


Until C99, you pretty much had to do it like that. Plus many people
consider it a good idea to keep your declarations in one place for
easier reference. Spraying declarations around through the body of
your code makes it a lot harder to follow.

> And I mean ALL variables, including those that are nested in
>deep fors and ifs...


I agree, this is often a bad idea.

>I don’t see any obvious performance gains


Again, C doesn't say.

> unless they do it to remember what they are using...


Which may be a performance gain in itself of course

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
 
Reply With Quote
 
Nick Landsberg
Guest
Posts: n/a
 
      01-29-2004


Christian Bau wrote:
> In article <bvbuvg$2pub$(E-Mail Removed)>,
> Papadopoulos Giannis <(E-Mail Removed)> wrote:
>
>
>>a) pre vs post increment/decrement
>>
>>I have read somewhere that:
>>
>>³Prefer pre-increment and -decrement to postfix operators. Postfix
>>operators (i++) copy the existing value to a temporary object, increment
>>the internal value, and then return the temporary. Prefix operators
>>(++i) increment the value and return a reference to it. With objects
>>such as iterators, creating temporary copies is expensive compared to
>>built-in ints.²

>
>
> I bet you didn't read that in a book about C.


This actually depends on the underlying chip architecture,
which is probably off-topic here.

>
>
>>b) I find that realloc() calls sometimes take more time to complete than
>>malloc() calls. Is this the general case?

>
>
>>c) Why do some people declare all the variables at the start of each
>>function? And I mean ALL variables, including those that are nested in
>>deep fors and ifs... I don¹t see any obvious performance gains - unless
>>they do it to remember what they are using...

>
>
> You worry too much about performance, and you worry too much about the
> wrong kind of performance. First try to write code that is bug-free and
> readable. That is the most important thing.


AMEN!

>
> If there is need to make your code faster: First measure. Get yourself a

^^^^
The key word is "need". What are the performance requirements? You
mean you didn't get any from the customer? Shame on you! This will
tell you how fast if MUST be in order to be acceptable.

> profiler, learn how to use it, learn how to interpret the numbers. Then
> before trying to figure out how to make an operation faster that you do
> a million times, figure out how to do it only 100,000 times or 1000
> times. That's how you make a program fast.


Agreed 1,000%! However, often after the developer has already
written code which uses foo() hundreds of thousands of times,
there is usually an emotional unwillingness to admit that a better
algorithm would do the trick and then they try to optimize foo(), even
if it's a standard library call. Start with requirements, as above,
design your algorithms, protoype and measure those which are going
to be invoked most often in order to find out if there will be
a problem. It's not just the efficiency (or lack thereof) in any
module, it's cpu-cost times frequency of use.

This holds for any language, not just C.
Sheesh, this IS [OT].

--
"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch

 
Reply With Quote
 
Nick Landsberg
Guest
Posts: n/a
 
      01-29-2004


E. Robert Tisdale wrote:

> Papadopoulos Giannis wrote:
>
>> a) pre vs post increment/decrement
>>
>> I have read somewhere that:
>>
>> “Prefer pre-increment and -decrement to postfix operators. Postfix
>> operators (i++) copy the existing value to a temporary object,
>> increment the internal value, and then return the temporary.
>> Prefix operators (++i) increment the value
>> and return a reference to it. With objects such as iterators,
>> creating temporary copies is expensive compared to built-in ints.”

>
>
> This must be a reference to
> overloaded increment and decrement operators in C++.
>
> Favoring pre-decrement/increment over post decrement/increment
> operators is a good habit for C programmers who must also
> write C++ programs. Otherwise, it is a matter of style.
>
>> A modern compiler wouldn’t make the optimization, so
>>
>> i++;
>>
>> and
>>
>> ++i;
>>
>> would give the same instructions?

>
>
> Yes.
>



For this trivial example, yes.

For the case of j = i++; vs. j = ++i;
(which are very different in intent), the
emitted code SHOULD be different,
unless you have a broken compiler.

The efficiency of the constructs to implement
these is a function of the underlying chip
architecture and not a language issue.


 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      01-30-2004
Mark McIntyre wrote:
> Papadopoulos Giannis <(E-Mail Removed)> wrote:
>

.... snip ...
>
> > b) I find that realloc() calls sometimes take more time to
> > complete than malloc() calls. Is this the general case?

>
> The standard doesn't say.


However, if you think about typical implementations, _sometimes_
it is necessary to allocate a whole new block of memory and copy
old data over to it. It will normally take longer to copy than to
not copy.

>
> > c) Why do some people declare all the variables at the start
> > of each function?

>
> Until C99, you pretty much had to do it like that. Plus many people
> consider it a good idea to keep your declarations in one place for
> easier reference. Spraying declarations around through the body of
> your code makes it a lot harder to follow.


IMO if those declarations are getting awkwardly far away from the
place they are used, you are writing overly large functions in the
first place.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
E. Robert Tisdale
Guest
Posts: n/a
 
      01-30-2004
CBFalconer wrote:

> Mark McIntyre wrote:
>
>>Until C99, you pretty much had to do it like that. Plus many people
>>consider it a good idea to keep your declarations in one place for
>>easier reference. Spraying declarations around through the body of
>>your code makes it a lot harder to follow.

>
> IMO if those declarations are getting awkwardly far away
> from the place they are used,
> you are writing overly large functions in the first place.


I agree.
And moving the declarations closer to the point of first use
is the first step in decomposing the function
into a set of smaller functions
that the compiler can inline automatically.

 
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
data perfomance? Scott Reynolds ASP .Net 3 03-01-2005 01:54 PM
CreateInstranceAndUnwrap slow perfomance Gnanaprakash Rathinam ASP .Net 5 12-30-2004 09:18 PM
Server perfomance Fredrik Melin ASP .Net 1 10-27-2004 11:45 AM
perfomance an ip-route-cache on a router Ralf Huelsmann Cisco 1 08-15-2004 03:09 PM
Optimizing perfomance on T3 line Christoph Schad Cisco 12 01-01-2004 08:40 PM



Advertisments