Re: guidelines for code reuse vs. one-function-per-file?

[OndÅej BÃlka <neleai at seznam dot cz>]

On Wed, May 07, 2014 at 02:13:26PM -0700, Roland McGrath wrote:
> 
> There's a tension in the other direction toward letting the compiler
> decide when inlining is optimal and when not (especially when it often
> might decide to inline, clone, and outline, so it's been "inlined" to
> two call sites but the bulk of the subroutine is in the shared clone).
> That leads toward putting multiple functions in one file so that the
> compiler can arrange to make them share code.  But I think we should
> just not worry about this and instead tend strongly toward separate
> files.  I think the optimization issue would be addressed better by
> someone working on using gcc's LTO to build our DSOs.
> 
> 
Roland that is not enough, gcc LTO without profiling information will do
inlining wrong function, so you need also profiling support.

Gcc with lto typically does not gain much from inlining alone as users
already optimized all functions that make performance impact.

Still gcc inlining is just a heuristic so it will make mistakes. A
common case is function that looks big so gcc will not inline it but
most of it is dead once inlined so forcing inline is correct.

Main benefit of lto is dead code removal in cold functions as hot paths
are typically already well optimized.

As for code duplication goes you could always make a common header and
add a static inline functions there.