Consider that Taligent's complex number implementation makes addition and subtraction functions inline (fairly short); but, multiplication and division are regular functions because they are longer--the overhead for a call is less important and code size is more important. Here, the efficiency consideration together with the low probability of a future change makes an inline a good idea.

System performance can decrease by making something inline; code size might increase due to duplication of code, and that increases the amount of code that must fit in ROM or be paged off disk. One extra trip to the disk costs around 2,000 subroutine calls (the faster the processor, the more it costs). Also, once a function is longer than a couple of lines, the call overhead is a small fraction of the total time. Additionally, the calling conventions of Taligent's final runtime will make the overhead even smaller. You don't save much by making it inline.

If you don't know that your implementation must be inline, do not make it inline. Build it normally and then measure the performance. Experience has shown again and again that programmers spend lots of time optimizing code that hardly ever gets executed, while totally missing the real bottlenecks.

NOTE For more information about inlines and efficiency, refer to
The Psychology of Computer Programming (Weinberg), and to Programming Pearls and Writing Efficient Programs (Bentley).

The empirical approach is much more reliable. Although better algorithms or smarter data structures generally buy you a lot more performance than random code tweaking, there is a legitimate role for such inlines, and there are many in the Taligent Application Environment. However, when a Taligent engineer wishes to make a function inline, the engineer must have either a compelling argument or objective performance data to sway the architect to approve it.