... 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
*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.