Program size, linking matter, and static this()

[Andrei Alexandrescu]

On 12/16/11 3:28 PM, Steven Schveighoffer wrote:
> On Fri, 16 Dec 2011 14:48:33 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 12/16/11 1:23 PM, Steven Schveighoffer wrote:
>>> I disagree with this assessment. It's good to know the cause of the
>>> problem, but let's look at the root issue -- reflection. The only reason
>>> to include class information for classes not being referenced is to be
>>> able to construct/use classes at runtime instead of at compile time. But
>>> if you look at D's runtime reflection capabilities, they are quite poor.
>>> You can only construct a class at runtime if it has a zero-arg
>>> constructor.
>>>
>>> So essentially, we are paying the penalty of having runtime reflection
>>> in terms of bloat, but get very very little benefit.
>>
>> I'd almost agree, but the code showed doesn't use Object.factory(). So
>> that shouldn't be linked in, and shouldn't pull vtables.
>
> You cannot know until link time whether factory is used when compiling
> individual files. By then it's probably too late to exclude them.

I'm not an expert in linkers, but my understanding is that linkers 
naturally remove unused object files. That, coupled with dmd's ability 
to break compilation output in many pseudo-object files, would take care 
of the matter. Truth be told, once you link in Object.factory(), bam - 
all classes are linked.

> The point is that you can instantiate unreferenced classes simply by
> calling them out by name.

Yah, but you must call a function to do that.

> I'm not pushing for runtime reflection, all I'm saying is, I don't think
> it's worth changing how the library is written to work around something
> because the *compiler* is incorrectly implemented/designed.
>
> So why don't we just leave the code size situation as-is? 500kb is not a
> terribly significant amount, but dlls are on the horizon (Walter has
> publicly said so). Then size becomes a moot point.
>
> If we get reflection, then you will find that having excluded all the
> runtime information when not used is going to hamper D's reflection
> capability, and we'll probably have to start putting it back in anyway.
>
> In short, dlls will solve the problem, let's work on that instead of
> shuffling around code.

I think there are more issues with static this() than simply executable 
size, as discussed. Also, adding dynamic linking capability does not 
mean we give up on static linking. A lot of programs use static linking 
by choice, and for good reasons.


Andrei