Tom St Denis wrote: > What you really should do, is profile your code, then create "static > inline" or macro copies of heavily used (and not overly large) pieces of > code. And even then, inlining code doesn't always help. You don't have to go to the trouble of inlining things manually, the compiler can do a much better job of estimating whether that's advantageous or not. Just mark functions that are not for export as static and the compiler will now have a large range of optimizations that it can automatically perform, including but not limited to inlining them. This is a case where having support/helper functions in the same .c file as the exportable functions that use them makes a great deal of sense. The key word in the original statement was exportabe: > This is why you should re-factor your code as to contain only one [or as > few as possible] exportable functions per unit. In general the compiler can do the best job when it can see everything at once, which is why currently so much work is being poured into developing the LTO branch, which will allow the compiler do certain optimizations as if the entire program was a single compilation unit even though it was compiled separately. Brian
