plans vis-a-vis inline functions and templates

[Lars Knoll]

On Sunday 14 December 2003 18:53, Darin Adler wrote:
> Hi folks.
>
> At Apple, we have a problem with our WebCore framework; it takes a long
> time to link, and it's very large (62 MB) when compiled with debugging
> symbols and -O0.

Link time is a problem of ld. Michael Matz from SuSE and myself had a look at 
this in Summer, and managed to get rid of a few places where the linker had 
quadratic behaviour. Especially for large C++ projects this improved link 
time dramatically (for Qt link time with debugging symbols went down from 
approx 3 minutes to about 20 secs on my machine). Most of these changes 
should be in the CVS version of GNU binutils by now (as it looks one fix for 
weak symbol merging is still missing, but that should come in soon as well).

> I suspect one of the big reasons for the huge size and slow link time
> is template instantiation. As described in the gcc manual
> <http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Template-
> Instantiation.html>, you can end up with lots of extra copies of
> functions if you just let things work the automatic way.
>
> I suspect another of the reasons is that khtml code (and kjs code,
> perhaps) uses inline function definitions in places where it shouldn't.
> A big example is virtual inline functions. Even though there's no rule
> against having a function be both virtual and inline in C++, in
> practice the inlining does no good except when the method is called
> directly with a class name qualifier. But khtml has a ton of virtual
> inline functions, and I think they are doing only harm, no good.

It's IMO a good idea to outline all virtual methods. 

Noone did it in KDEs CVS as noone looked at it as critical. Multiple 
instantiations of the methods usually get resolved at link time, so it 
shouldn't really matter for the resulting binary.

> For a function that won't be inlined in practice, like a virtual inline
> function, or one that is too complicated to be inlined, marking it
> inline and putting it in the header has a big cost, because it will be
> compiled into each separate object file. So if 50 .cpp files all
> include that header, we get 50 copies of that function that the linker
> has to look at.
>
> A separate issue it's a tricky tradeoff whether to define a function
> inline or not. Even for simple functions, inlining them can easily
> result in bigger, slower code.
>
> All that having been said, I can understand the desire to have the
> simple functions right there in the header file, and for C++ that
> effectively marks them inline. I don't think it's worth the additional
> compile and link time, though.
>
> I'd like to do a few things about this. I wont get to this until next
> month, probably, but here are some things I am planning to do:
>
>      1) compile with -fno-implicit-templates, adding explicit
> instantiation
>      2) get rid of all virtual inlines by moving the function
> definitions to the .cpp file or removing the inline keyword
>      3) compile with -Winline and consider moving some other inline
> function definitions, for functions which are not getting inlined in
> practice
>
> Please let me know what you think of this plan.

Sounds good. I don't think doing explicit template instantiation is worth the 
hazzle though. 

Lars