On 2011-12-22 08:14:21 +0000, Jonathan M Davis <jmdavisp...@gmx.com> said:
On Thursday, December 22, 2011 00:05:58 Walter Bright wrote:
We must deal with our imperfect tools as they are. For example, I am not
going to rewrite the Linux ld linker, and the OSX linker, and the FreeBSD
linker, etc.
If the compiler and/or linker don't strip unused symbols, then how on earth is
importing the module _not_ going to pull in everything in it save for
uninitialized templates?
I'm pretty sure, even though it's been a long time I've looked at those
details, that the problem is caused by classes. Basically, the typeinfo
for all classes in a module are referenced by the generated module info
structure. The class's typeinfo points to many things including the
default constructor and vtable, the vtable points to all virtual
functions, which finally points to everything used by those functions.
You can thus easily have all the code in the module referenced
indirectly by the module info, so the linker can't strip it. That might
be why std.datetime has a heavy footprint, even when you use only a
small part of it. But still, you should look at the generated code to
test this hypothesis.
The benefit of referencing classes within module info: you can
instantiate them using Object.factory, if they have a default
constructor. We pay a heavy price compared to what we get with this
very limited runtime reflection.
Things you can do if this hypothesis proves to be correct: make it so
that any virtual function in your classes are short and do not depend
on heavy functions, as all the code referenced by those functions will
be dragged along. Don't forget that final functions are still virtual
if they override a function in a base class or defined in an interface.
Also, don't use a class if you don't need one, or if you need one put
it in a separate module that you only import when you need it.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
