> It does, but increases the exe size of the first example from 180kb to 617kb!
> 180kb is when compiled using build/rebuild/jake etc (no library) and the 617kb
> is when using dmd+lib only. Same flags in both cases: none at all

Let's say you have a template instance, TI. It is declared in two modules, M1 and M2:

-----------M1------------
TI
A
-----------M2------------
TI
B
-------------------------

M1 also declares A, and M2 also declares B. Now, the linker is looking to resolve TI, and the first one it finds is one in M1, and so links in M1. Later on, it needs to resolve B, and so links in M2. The redundant TI is discarded (because it's a COMDAT).

However, suppose the program never references A, and A is a chunk of code that pulls in lots of other bloat. This could make the executable much larger than if, in resolving TI, it had picked M2 instead.

You can control which module containing TI will be pulled in by the linker to resolve TI, by specifying that module first to lib.exe.

You can also put TI in a third module that has neither A nor B in it. When compiling M1 and M2, import that third module, so TI won't be generated for M1 or M2.

Walter Bright wrote:
>> It does, but increases the exe size of the first example from 180kb to 617kb!
> 
>  > 180kb is when compiled using build/rebuild/jake etc (no library) and the 617kb
>  > is when using dmd+lib only. Same flags in both cases: none at all
> 
> Let's say you have a template instance, TI. It is declared in two modules, M1 and M2:
> 
> -----------M1------------
> TI
> A
> -----------M2------------
> TI
> B
> -------------------------
> 
> M1 also declares A, and M2 also declares B. Now, the linker is looking to resolve TI, and the first one it finds is one in M1, and so links in M1. Later on, it needs to resolve B, and so links in M2. The redundant TI is discarded (because it's a COMDAT).
> 
> However, suppose the program never references A, and A is a chunk of code that pulls in lots of other bloat. This could make the executable much larger than if, in resolving TI, it had picked M2 instead.
> 
> You can control which module containing TI will be pulled in by the linker to resolve TI, by specifying that module first to lib.exe.
> 
> You can also put TI in a third module that has neither A nor B in it. When compiling M1 and M2, import that third module, so TI won't be generated for M1 or M2.


This is definately useful; thanks for this and for being so expediant with the lib change.

In this particular case I suspect something else is the cause, since (a) Tango is deliberately very granular (b) the map file for the huge exe is showing gobs of data that shouldn't exist <g>

kris wrote:
> In this particular case I suspect something else is the cause, since (a) Tango is deliberately very granular (b) the map file for the huge exe is showing gobs of data that shouldn't exist <g>

For a quick & dirty test, try reversing the order the object files are presented to lib.

Walter Bright wrote:
> kris wrote:
> 
>> In this particular case I suspect something else is the cause, since (a) Tango is deliberately very granular (b) the map file for the huge exe is showing gobs of data that shouldn't exist <g>
> 
> 
> For a quick & dirty test, try reversing the order the object files are presented to lib.

there's a couple of hundred :-D

kris wrote:
> Walter Bright wrote:
>> For a quick & dirty test, try reversing the order the object files are presented to lib.
> 
> there's a couple of hundred :-D

Do the ones that were giving the undefined reference before the changes to lib.

Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> For a quick & dirty test, try reversing the order the object files are presented to lib.
>>
>>
>> there's a couple of hundred :-D
> 
> 
> Do the ones that were giving the undefined reference before the changes to lib.

The lib itself is actually built via a single D module, which imports all others. This is then given to Build to construct the library. Thus I don't have direct control over the ordering. Having said that, it appears Build does something different when the modules are reordered; Likely changing the order in which modules are presented to the lib.

By moving things around, I see a change in size on the target executable between -4kb to +5kb

kris wrote:
> Walter Bright wrote:
> 
>> kris wrote:
>>
>>> Walter Bright wrote:
>>>
>>>> For a quick & dirty test, try reversing the order the object files are presented to lib.
>>>
>>>
>>>
>>> there's a couple of hundred :-D
>>
>>
>>
>> Do the ones that were giving the undefined reference before the changes to lib.
> 
> 
> The lib itself is actually built via a single D module, which imports all others. This is then given to Build to construct the library. Thus I don't have direct control over the ordering. Having said that, it appears Build does something different when the modules are reordered; Likely changing the order in which modules are presented to the lib.
> 
> By moving things around, I see a change in size on the target executable between -4kb to +5kb
> 

I've been messing with the response file handed to the librarian (via lib @foo); moving modules around here and there, reordering big chunks etc. Have yet to see a notable change in the resulting exe after relinking against each lib version.

kris wrote:
> I've been messing with the response file handed to the librarian (via lib @foo); moving modules around here and there, reordering big chunks etc. Have yet to see a notable change in the resulting exe after relinking against each lib version.

Then look at the .map file to see what was linked in to the larger file that wasn't in the smaller. Remove that module from the library. Link again, and see what was unresolved. Rinse, repeat, and you'll see what was pulling it all in.

On Wed, 21 Feb 2007 01:47:53 -0800, kris wrote:

> kris wrote:
>> Walter Bright wrote:
>> 
>>> kris wrote:
>>>
>>>> Walter Bright wrote:
>>>>
>>>>> For a quick & dirty test, try reversing the order the object files are presented to lib.
>>>>
>>>>
>>>>
>>>> there's a couple of hundred :-D
>>>
>>>
>>>
>>> Do the ones that were giving the undefined reference before the changes to lib.
>> 
>> 
>> The lib itself is actually built via a single D module, which imports all others. This is then given to Build to construct the library. Thus I don't have direct control over the ordering. Having said that, it appears Build does something different when the modules are reordered; Likely changing the order in which modules are presented to the lib.
>> 
>> By moving things around, I see a change in size on the target executable between -4kb to +5kb
>> 
> 
> I've been messing with the response file handed to the librarian (via lib @foo); moving modules around here and there, reordering big chunks etc. Have yet to see a notable change in the resulting exe after relinking against each lib version.


Is build really a reliable means of testing this?  I mean, it's produced unusual differences in binary size in the past (granted not of that magnitude).  Of course, this is a different case too, in which a library is being created.

Just out of curiousity, does rebuild do the same thing?

-JJR

Walter Bright wrote:
> kris wrote:
> 
>> I've been messing with the response file handed to the librarian (via lib @foo); moving modules around here and there, reordering big chunks etc. Have yet to see a notable change in the resulting exe after relinking against each lib version.
> 
> 
> Then look at the .map file to see what was linked in to the larger file that wasn't in the smaller. Remove that module from the library. Link again, and see what was unresolved. Rinse, repeat, and you'll see what was pulling it all in.

That's exactly what I'm doing, and I agree there seems to be something odd going on here. With ~200 modules, it's no slam-dunk to isolate it :)