plans vis-a-vis inline functions and templates

[Darin Adler]

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.

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.

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.

     -- Darin