plans vis-a-vis inline functions and templates

[Dirk Mueller]

On Sunday 14 December 2003 18:53, Darin Adler wrote:

> 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.

Well, thats what you get when you use -O0. If you want to have precise 
backtrace info, then use -fno-inline. -O0 produces objects that are insanely 
large, and will not show all bugs, since compiling without -O2 will make the 
compiler skip some dependency analysis steps. 

With other words, if your code is buggy then it might be that a release build 
with -O2 behaves differently than your debug build. For our purposes, as we 
test while we develop, this is unacceptable. It is important that the debug 
builds we use as developers behave the very same for the users. If you have a 
200 people Q&A department behind you that will test the release build then 
thats of course not an issue for you. 

> include that header, we get 50 copies of that function that the linker
> has to look at.

its a weak symbol. we link every subdirectory individually to convenience 
libraries, so the extra symbols die in this step, producing only a minimal 
overhead. I guess you should do the same, since link time usually grows O(n) 
with the number of libs/object files. when you link the object files into 
convenience libs, and then only link the convenience libs together, the last 
step will be a lot faster. 

BTW, Qt developers have a mode in their build system where they do a build 
with .o of the one source file they work on + archive of all the other files. 
linking the newly recompiled single .o to the archive takes almost no time 
compared to relinking all the bunch of .o files to a new library. 

In the past, I have removed many "virtual" declarations from methods which 
don't need them, and de-inlined many of those which had a nontrivial 
implementation. I also regularly inline short methods to reduce code bloat. 

This is not the case for those "virtual bool isFoo() const { return true; }" 
variants. 

For me, code readability is more important than link time. With the recent 
speedups in GNU ld, linking debug build of khtml takes only ~ 2 seconds here. 
I don't think I would notice if it takes 1.5s instead.

I guess it would also annoy me more when I'd have to find the "important" 
methods inside all this mess of triviality. I only have a 19" screen, so the 
amount-of-code I can see "in one page" is important to me. 

So, feel free to waste your time on it, but I don't think it would be one of 
the things we'd be eager to merge. At least I won't.