Too many one line function calls

N

Nitin

Ppl ,
Want to have ur opinions on having function calls like the one stated
below:


function funcA ( struct A *st_A , struct B *st_B )
{
st_A->a = st_B->a



}


Basically Is it a nice programming practice to have functions like this

especially when we can access both the structures in the calling
program ???
I want to know what will b the pros and cons of such calls ??
Will such calls effect the speed of execution by loading and unloading
the stack ????
Plz keep in mind that I m woking on a archaic system :) and I m not the

one who wrote the code ...

Thanks in advance
Nitin
 
J

jacob navia

Nitin said:
Ppl ,
Want to have ur opinions on having function calls like the one stated
below:


function funcA ( struct A *st_A , struct B *st_B )
{
st_A->a = st_B->a



}


Basically Is it a nice programming practice to have functions like this

especially when we can access both the structures in the calling
program ???
I want to know what will b the pros and cons of such calls ??
Will such calls effect the speed of execution by loading and unloading
the stack ????
Plz keep in mind that I m woking on a archaic system :) and I m not the

one who wrote the code ...

Thanks in advance
Nitin

Instead of doing the assignment directly you pay:
1: The cost of pushing the arguments in the stack
2: the cost of a function call instruction
2: the cost of establishing a stack frame
3: The cost of destroying the stack frame
4: the cost of a return instruction.

You gain flexibility in software design. The details of
the assignment and the structure of the arguments are
hidden behind a function call. If you have many
assignments like this you can change them very easily.
Not so if you have written the assignment directly
all over the code.

What is better depends on the situation, the speed of the
machine, the importance of code size and code speed, etc.

There is no clear cut decision here. It is a matter of weighting
the costs and the advantages.
 
W

Walter Roberson

:Want to have ur opinions on having function calls like the one stated
:below:

:function funcA ( struct A *st_A , struct B *st_B )
:{ st_A->a = st_B->a >}

:Basically Is it a nice programming practice to have functions like this

Yes.


:especially when we can access both the structures in the calling
:program ???

I'm not srue what you mean there?


:I want to know what will b the pros and cons of such calls ??
:Will such calls effect the speed of execution by loading and unloading
:the stack ????

With code this simple, your compiler may be able to inline the
operation, replacing the call with direct execution of the effects.

If a call is used, the overhead depends upon the ABI and upon the
architecture. When small numbers of values are passed in, it would be
common (but not certain) to pass the values in registers; the calling
program would see that the registers themselves are not being modified
and so would not need to save the registers upon the stack. The
return address may have to go on the stack, but that's dependant
upon the architecture and ABI: some ABIs are set up to save the
return address in a register, and it is up to the called routine to
save that register if the called routine decides the code is complex
enough to warrant it. On some architectures, the generated code might
be as little as move (A1),(A0); branch A7

Matters such as these, which require a fair knowledge of the architecture
and of the ABI, are beyond the C specifications, so they are not
usually discussed in comp.lang.c .


:plz keep in mind that I m woking on a archaic system :) and I m not the
:eek:ne who wrote the code ...

Suppose you were able to save two instructions per invocation by
doing the assignment directly, but doing so would require rewriting
the code. How long would it take to rewrite the code? How much
clarity would be lost in the code? Now, how much compute time would
be saved over the complete life of the program by not having to
execute those two instructions?

Say the rewrite took a working day (8 hours) and [considering you said
the system was archaic] suppose the machine runs at 500 MHz per clock
cycle, 2 cycles per instruction, so 4 cycles saved per invocation by
your optimization.

8 hours * 60 minutes/hour * 60 seconds/minute * 500,000,000 cyles/s /
(4 cycles/invocation) = 3,600,000,000,000 invocations

Thus you would need 3.6 trillion invocations just to break even.
Is that likely? Is shaving off an 8th of a microsecond per call
worth the effort?

When you are dealing with optimizations, worry about the parts of
your code that are -proven- to cause a bottleneck. For the rest
of your code, write it in the manner that will be most -maintainable-,
because the human maintenance for the rest of the code is likely to
consume far more time than would be used by the processor.
 
E

E. Robert Tisdale

Nitin said:
I want to have your opinions
on having function calls like the one stated below:

function funcA(struct A *st_A , struct B *st_B) {
st_A->a = st_B->a
}

You have confused C with Fortran.
A good C programmer might write:

typedef struct A A;
typedef struct B B;

inline static
A* funcA(A* pA, const B* pB) {
pA->a = pB->a;
return pA;
}

to implement a function that modifies an object of type A.
It is a nice programming practice to have functions like this
especially when we can access both of the structures in the calling program.
I want to know, "What will be the pros and cons of such calls?"
Will such calls effect the speed of execution
by loading and unloading the stack?

Not if you declare then to be *inline*.
 
N

Nitin

Ppl ,...
Thanks a lot for all the suggestions ..

the function defination which I had given was just a dummy defination
... not taken out of the real code ...
Also the function has not been defined as inline ..
so i need to make them inline...
also is there anyway by which we can check whether the function is
being invoked as inline ???
because if i m not wrong the inline invocation depends not just on
function being invoked as inline ..

I guess i will let these functions remain as it is instead of wasting
my time removing these function calls
Also i didn't peek to the end of the message .. i skipped it altogether
and then went through it again :)
Thnaks a lot
Nitin
 
O

Old Wolf

Nitin said:
Ppl ,
Want to have ur opinions on having function calls like
the one stated below:

Ur has been dead for millennia so it would be hard to
get its opinion.
function funcA ( struct A *st_A , struct B *st_B )
{
st_A->a = st_B->a
}


Basically Is it a nice programming practice to have functions like this
especially when we can access both the structures in the calling
program ???
I want to know what will b the pros and cons of such calls ??
Will such calls effect the speed of execution by loading and unloading
the stack ????

If the function is not in a place where the compiler can
inline it, then it might marginally slow down execution.

But it would enable you to change its behaviour later on,
without having to change every assignment statement.
Plz keep in mind that I m woking on a archaic system :) and I m not the
one who wrote the code ...

Maybe you could ask the opinion of Ur after all, then
 
D

Dan Pop

In said:
Want to have ur opinions on having function calls like the one stated
below:


function funcA ( struct A *st_A , struct B *st_B )
{
st_A->a = st_B->a;
}


Basically Is it a nice programming practice to have functions like this
especially when we can access both the structures in the calling
program ???

Such functions are typically used to improve the code's maintenability
when there is a significant probability that the body of the function
will change later in the program's life.

If performance is an issue (and only then), the trivial original version
can be implemented as a function-like macro. Switching to a real
function later (if necessary) is straightforward.

Such functions may also be used as callbacks. They have to remain
functions in this case.

So, without an intimate knowledge of the program, it's hard to say
whether using such functions was a good thing or not.

Dan
 
E

E. Robert Tisdale

Dan said:
Such functions are typically used to improve the code's maintenability
when there is a significant probability that
the body of the function will change later in the program's life.

If performance is an issue (and only then),
the trivial original version can be implemented as a function-like macro.
Switching to a real function later (if necessary) is straightforward.

Such functions may also be used as callbacks.
They have to remain functions in this case.

Nonsense! A good C89 programmer might write:
> cat main.c
#include <stdio.h>

typedef struct A {
int a;
} A;

typedef struct B {
int a;
} B;

void g(A* (*f)(A*, const B*)) {
A a;
const
B b = {33};
const
A c = *f(&a, &b);
fprintf(stdout, "c.a = %d\n", c.a);
}

A* funcA(A* pA, const B* pB) {
pA->a = pB->a;
return pA;
}

#define funcA(pA, pB) \
((pA)->a = (pB)->a, (pA))

int main(void) {
A a;
const
B b = {13};
const
A c = *funcA(&a, &b);
fprintf(stdout, "c.a = %d\n", c.a);
g(funcA);
return 0;
}
> gcc -Wall -std=c89 -pedantic -o main main.c
> ./main
c.a = 13
c.a = 33
So, without an intimate knowledge of the program,
it's hard to say whether using such functions was a good thing or not.

inline functions (as opposed to manually inlining functions)
has always neen a good idea
even if they must be implemented as C preprocessor macros.
 
J

Jesse Meyer

jacob navia said:
Instead of doing the assignment directly you pay:
1: The cost of pushing the arguments in the stack
2: the cost of a function call instruction
2: the cost of establishing a stack frame
3: The cost of destroying the stack frame
4: the cost of a return instruction.

You gain flexibility in software design. The details of
the assignment and the structure of the arguments are
hidden behind a function call. If you have many
assignments like this you can change them very easily.
Not so if you have written the assignment directly
all over the code.

Why not make a macro with the naming convention like a function?
You get the flexibility of software design (since you can always
replace it with a function down the road) and the speed of
assigning it directly.

Or am I missing something obvious?
 
K

Keith Thompson

jacob navia said:
That's a solution too, but the original poster asked about
a function...

What's a solution too? Please provide some context.

In any case, we aren't restricted to providing just what was asked
for. If the OP doesn't find a solution useful, he doesn't have to use
it; it might be useful for someone else.
 

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

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top