469,628 Members | 1,016 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,628 developers. It's quick & easy.

Too many one line function calls

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

Nov 14 '05 #1
10 2028
Nitin wrote:
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.
Nov 14 '05 #2
In article <11**********************@z14g2000cwz.googlegroups .com>,
Nitin <ni******@gmail.com> wrote:
: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
:one 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.
--
Admit it -- you peeked ahead to find out how this message ends!
Nov 14 '05 #3
Nitin wrote:
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*.
Please keep in mind that I'm woking on a archaic system :)
and I'm not the one who wrote the code.

Nov 14 '05 #4
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

Nov 14 '05 #5
Nitin wrote:
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

Nov 14 '05 #6
In <11**********************@z14g2000cwz.googlegroups .com> "Nitin" <ni******@gmail.com> writes:
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
--
Dan Pop <Da*****@ifh.de>
Nov 14 '05 #7
Dan Pop wrote:
Nitin writes:
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.


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.
Nov 14 '05 #8
jacob navia <ja***@jacob.remcomp.fr> wrote:
Nitin wrote:
function funcA ( struct A *st_A , struct B *st_B )
{
st_A->a = st_B->a

}

I want to know what will b the pros and cons of such calls ??


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?

--
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
Nov 14 '05 #9
That's a solution too, but the original poster asked about
a function...
Nov 14 '05 #10
jacob navia <ja***@jacob.remcomp.fr> writes:
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

23 posts views Thread by Mark Dickinson | last post: by
40 posts views Thread by Abby | last post: by
23 posts views Thread by FrancisC | last post: by
34 posts views Thread by Roman Mashak | last post: by
23 posts views Thread by Kaz Kylheku | last post: by
14 posts views Thread by Samant.Trupti | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.