Functioning In C

A

Abhishek

How Does Functioning(Breaking in seperate block according to the logic
using functions) a Programme effect the performance of the programme
 
M

Mike Wahler

Abhishek said:
How Does Functioning(Breaking in seperate block according to the logic
using functions) a Programme effect the performance of the programme

Negligibly. Drastically. Not at all. Context, context, context.

The organization of program logic into functions will
indeed greatly affect programmer productivity.


-Mike
 
D

Darrell Grainger

How Does Functioning(Breaking in seperate block according to the logic
using functions) a Programme effect the performance of the programme

The generic answer is... it depends. It is almost guaranteed that there
will be some overhead involved with functions. This means there will be
some deduction of performance. I say ALMOST guaranteed because it is never
100% guaranteed.

On some compilers everything might become linear assembly. From a source
code view there are a lot of functions and branching. From the machine
language view everything is linear as if the program was written as one
big function called main().

In other circumstances, a function call could be translated to a branch
instruction. On processors with caching and pipelines, a branch is very
costly. Breaking a program into many small functions could double or
triple the running time of the program.

Bottom line, it depends on many factors. All of these factors are outside
the domain of comp.lang.c. What you are looking for is more in line with
specific implementations of C language. Tere should be newsgroups to help
you out if you focus on your operating system and compiler.
 
O

osmium

Abhishek said:
How Does Functioning(Breaking in seperate block according to the logic
using functions) a Programme effect the performance of the programme

A copy of each argument must be moved to the "stack". The processor
probably has something like 'call' and 'return' as instructions designed
especially with the intent of there *being* a stack. And one of each of
those must be executed. The space for the stack must be managed which might
possibly be a single add or subtract instruction. The result, if any,
probably has to be moved someplace special. I'm thinking something of the
order of a half-dozen instructions plus one instruction per parameter.

Naturally, all of this depends on the microprocessor used and the compiler
design. The short answer is that I would not avoid using functions because
of the overhead. If you are at the point where this is a potential problem
you should probably consider switching to assembly language. The compilers
I am familiar with are not really as good at "doing" registers and getting
all the good out of them as the human mind is.
 
A

August Derleth

How Does Functioning(Breaking in seperate block according to the logic
using functions) a Programme effect the performance of the programme

You really shouldn't worry about this too much unless you have to.

And you probably don't have to.

What you should worry about is how easy the program is to read,
understand, maintain, and change. Seperating it into functions greatly
helps that process. Seperating it into functions helps you break the
problem down into managable chunks, which can be easily solved one at
a time. Once all of the small problems have been solved, your big
problem has also been solved.

Finally, breaking down the problem also breaks down the solution. All
of those small solutions can be used again in a different program.
Code reuse is a great thing, and generating functions instead of just
writing one big main() is a simple, obvious means to that end.
 
C

cody

How Does Functioning(Breaking in seperate block according to the logic
using functions) a Programme effect the performance of the programme

if the function is rather big there is no real performance loss. if you
really care about speed use a macro.
 
N

NumLockOff

Mike Wahler said:
What are your premises for this statement?


What are your premises for this statement?

-Mike

What I gather from Cody's response is that
if the function is really small make a macro out of it to save the jumps and
push/pop registers.

If you have a silly func

SetTo12(int *px)
{
*px =12;
}


it is better to have the macro
#define SET_TO_12 (iii) iii=12

....

Well this example is too silly, but i hope you get the point..
 
J

Jarno A Wuolijoki

What I gather from Cody's response is that
if the function is really small make a macro out of it to save the jumps and
push/pop registers.

If that were the only advantage there would be little point in inlining.
The real speedup comes from that the compiler can perform a whole flock
of other optimizations when it integrates the piece of code in an
expression.

Consider e.g.

#define cat1(x) ((x)*2+1)
#define cat0(x) ((x)*2)
unsigned foo(unsigned x) {
return cat0(cat1(cat0(cat1(cat0(cat1(x))))));
}

This is optimizable to x*64+42. (Though whether it actually happens
is a different matter..)
 
M

Mike Wahler

NumLockOff said:
What I gather from Cody's response is that
if the function is really small make a macro out of it to save the jumps and
push/pop registers.

What "push/pop registers?" This is ISO C, remember.
If you have a silly func

SetTo12(int *px)
{
*px =12;
}


it is better to have the macro
#define SET_TO_12 (iii) iii=12

I almost always prefer a function over a macro,
especially when side effects are involved. I try
to always only use macros to express "magic numbers."
Well this example is too silly, but i hope you get the point..

I understand your point, but disagree with it, as
well as Cody's assertion that a macro will necessarily
give better performance than a macro.

The *only* way to accurately determine if one method
performs faster than another is to measure.

-Mike
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top