[OT] C function call cost.

[Flash Gordon]

... snip reply to Paul Hsieh ...

I think that is a strategic mistake. Using inline means you can
freely remove those pesky 3 to 10 or so line phrases from your
functions and give them a meaningful parametized name. You no
longer need added local variables for them. This enhances both
the readability and reliability of your code, without any runtime
penalty. Each function then becomes much shorter, deals with
fewer entities, and is much more easily verified by inspection.
Using something from the standard library as an example, compare:

which I believe to do the same job, with strlen and strcpy
embedded. Yet this might well generate the identical code to the
first example, assuming strlen and strcpy were defined as inline
functions. The readability, and the possibility of error, are now
much lower and higher respectively.

A side benefit of using inline will be that you develop more
useful and reusable functions for your application, which makes
the whole schmeer clearer, tauter, and more elegant.

And, using inline, you can always #define it away for porting to
compilers that don't understand.

I do use small functions, it's just that efficiency is not enough of a
concern for me to analyse whether it is better to use inline or not.
Instead I leave it up to the compiler to inline if it thinks it is
appropriate.

*If* efficiency becomes a concern *then* I will worry about profiling
and seeing if I should inline some functions or do something else to
speed it up. However, currently we can cope with a few hundred users
(which is all we need to cope with) on a reasonable server, so both us
and our customers are happy with the choices made by the compiler.

 

[Dave Thompson]

I knew it is OT, <snip>
What is the cost involved in a function call?

We don't talk about it because [depends on many factors ....]

If there is something like inlining call in c++, so that I can reduce the
cost?

Not officially in the C89 standard but in the "new" C99 standard.
But many compilers already had an extensions before, allowing you
to inline functions. See the documentation of your compiler.

Can I reduce function call cost by reducing number of argument, for example,
make them global?

Yes, it could speed up [but also could slow down ....]
So the answer is basically mu. If you really need to know if some-
thing is faster or not measure it. Or look at the assembler produced
by the compiler and try to guess from that.

If there is some really short function call that is the bottleneck, what can
I do?

float utterance_getData(Utterance utterance, int time, int dimension) {
return utterance->data[time][dimension];
}

How do you know that that is a bottleneck? Did you ever run your program
under a profiler to find out how much time that call takes? And if you're

Agree so far.

really that concerned with speed why do you use such a kind of function
at all? And why do you use floats? That only requires that the numbers
have to be converted first to double and than back to float all of the
time because calculations are always done in double.

On some machines, notably and commonly x86/87, but not everywhere and
not required by the standard. What is required is that _variadic_ or
unprototyped calls promote float to double; and it is _permitted_ that
all (other) floating-point computations can be done in precision (and
range) exceeding their nominal types. Stores (assignments) and
conversions (casts) are supposed to cut back to nominal type, but on
x86/87 it kills performance and gcc tries not to do so by default,
even if you say -ansi etc., unless you specifically say -ffloat-store.

- David.Thompson1 at worldnet.att.net

 

[Dan Pop]

On some machines, notably and commonly x86/87, but not everywhere and
not required by the standard. What is required is that _variadic_ or
unprototyped calls promote float to double; and it is _permitted_ that
all (other) floating-point computations can be done in precision (and
range) exceeding their nominal types. Stores (assignments) and
conversions (casts) are supposed to cut back to nominal type, but on
x86/87 it kills performance and gcc tries not to do so by default,
even if you say -ansi etc., unless you specifically say -ffloat-store.

And even with -ffloat-store, gcc will manage to break conformance, in
certain cases. It tends to ignore footnote 86 in C99 (well, it's not
normative in the first place, although its text *definitely* should be
normative).

Dan