On Fri, 16 Dec 2011 17:00:45 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 12/16/11 3:28 PM, Steven Schveighoffer wrote:
On Fri, 16 Dec 2011 14:48:33 -0500, Andrei Alexandrescu
<seewebsiteforem...@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.
Factory doesn't directly reference classes, it does so through the
moduleinfo tree/array (not sure what it is). So the way it works is, the
linker includes the module info because it's defined as static data, which
includes the vtable functions, and factory can instantiate non-referenced
classes because of this fact, not the other way around.
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.
Even statically linked programs might use runtime reflection.
I agree the issue is not static linking vs. dynamic linking, but dynamic
linking would hide the problem quite well.
Note that on Linux today, the executable is not truly static -- OS libs
are dynamically linked.
Another option is to disable runtime reflection via a compiler switch
(which would sever the ties between moduleinfo and classinfo). Then we
simply must make sure we don't use factory in the library anywhere.
-Steve
