Given a (fixed) body of code, it appears that retaining it all within one module, and splitting it into multiple modules, results in different executable sizes?

There's no real surprise that this would happen, but it's the actual difference that is cause for a little concern -- it appears that each module consumes 512 bytes minimum. This may actually be a linker thing, but perhaps not?

Why would this matter? Well, if you wind up using the 158 modules in the  Win32 project, that adds nearly 80KB to an application. Purely in module overhead. And, those headers are almost all enum, const, and struct.

This is in addition to the ~70KB of unused initializer from the Win32 headers, dicussed in the other topic. That's a whole lot of overhead for Win32 programs to carry -- especially if the target is mobile devices.

Obviously, you'd be doing something truly serious if you were actually using all those header modules! However, Win32 headers are not exactly a model in decoupled design (in C also), so you wind up with large numbers of them unintentionally.

Any ideas, Walter?

kris wrote:
> There's no real surprise that this would happen, but it's the actual difference that is cause for a little concern -- it appears that each module consumes 512 bytes minimum. This may actually be a linker thing, but perhaps not?

The way to see what's in an object file is to run obj2asm on it. It'll show exactly what's submitted to the linker.

Walter Bright wrote:
> kris wrote:
> 
>> There's no real surprise that this would happen, but it's the actual difference that is cause for a little concern -- it appears that each module consumes 512 bytes minimum. This may actually be a linker thing, but perhaps not?
> 
> 
> The way to see what's in an object file is to run obj2asm on it. It'll show exactly what's submitted to the linker.
> 

I'm aware of that, thanks.

Do you think you could comment on why it might be the linker? And how to compensate? You're probably one of the two ppl in the world who know OptLink ...

Also: are dmd obj files compatible with any other linker?

kris schrieb am 2007-01-24:
> Given a (fixed) body of code, it appears that retaining it all within one module, and splitting it into multiple modules, results in different executable sizes?
>
> There's no real surprise that this would happen, but it's the actual difference that is cause for a little concern -- it appears that each module consumes 512 bytes minimum. This may actually be a linker thing, but perhaps not?
[...]
> Any ideas, Walter?

Every non-trivial module contains (numbers are for Linux)
_D5module7__arrayZ
23 bytes code, 19 bytes stringtab, 18 bytes symtab

_D5module8__assertFiZv
24 bytes code, 23 bytes stringtab, 18 bytes symtab

_D5module9__modctorFZv
11+ bytes code, 23 bytes stringtab, 18 bytes symtab

In total 177 bytes, after stripping (strip --strip-all) 58 bytes.
The minimum overhead of an object file is about 800 bytes,
most of those are discared at link time.

Thomas

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> kris schrieb am 2007-01-24:
>> Given a (fixed) body of code, it appears that retaining it all within one module, and splitting it into multiple modules, results in different executable sizes?
>>
>> There's no real surprise that this would happen, but it's the actual difference that is cause for a little concern -- it appears that each module consumes 512 bytes minimum. This may actually be a linker thing, but perhaps not?
> [...]
>> Any ideas, Walter?
> 
> Every non-trivial module contains (numbers are for Linux)
> _D5module7__arrayZ
> 23 bytes code, 19 bytes stringtab, 18 bytes symtab
> 
> _D5module8__assertFiZv
> 24 bytes code, 23 bytes stringtab, 18 bytes symtab

These are the outstanding problem for exposing templates from library code.  And I don't understand why they are generated, since it seems like the code will be identical for each instance generated.  Couldn't they just have a static definition in the runtime?

> _D5module9__modctorFZv
> 11+ bytes code, 23 bytes stringtab, 18 bytes symtab

Only if the module as a static ctor though, right?

> In total 177 bytes, after stripping (strip --strip-all) 58 bytes.
> The minimum overhead of an object file is about 800 bytes,
> most of those are discared at link time.

Thanks for the info.


Sean

Sean Kelly schrieb am 2007-01-24:
> Thomas Kuehne wrote:
>> kris schrieb am 2007-01-24:

>> _D5module9__modctorFZv
>> 11+ bytes code, 23 bytes stringtab, 18 bytes symtab
>
> Only if the module as a static ctor though, right?

Also if a class/struct has a static ctor.

Thomas

kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> There's no real surprise that this would happen, but it's the actual difference that is cause for a little concern -- it appears that each module consumes 512 bytes minimum. This may actually be a linker thing, but perhaps not?
>>
>>
>> The way to see what's in an object file is to run obj2asm on it. It'll show exactly what's submitted to the linker.
>>
> 
> I'm aware of that, thanks.
> 
> Do you think you could comment on why it might be the linker?

Suggesting you look at what's submitted to the linker doesn't necessarily imply the linker is the cause. If it receives object files with more data in it (generated by the compiler) and dutifully links them, the output is still bigger ;).

> Also: are dmd obj files compatible with any other linker?

IIRC OMF (the format of dmd obj files) used to be the "standard" object format on Windows[1], and perhaps other OSs as well. That was a while back though. It wouldn't surprise me if optlink is the only recent linker to support it, but even if so you may be able to find some old versions of other linkers that support it.


[1]: Or was it still DOS back then? The MS OS at the time, anyway.

kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> There's no real surprise that this would happen, but it's the actual difference that is cause for a little concern -- it appears that each module consumes 512 bytes minimum. This may actually be a linker thing, but perhaps not?
>>
>>
>> The way to see what's in an object file is to run obj2asm on it. It'll show exactly what's submitted to the linker.
>>
> 
> I'm aware of that, thanks.

The words used suggested an unfamiliarity with the tools. I believe it's well worth the effort to master what's going on with object files and linking, especially for professional developers, and the tools obj2asm, /MAP, and dumpexe are marvelous aids.

> Do you think you could comment on why it might be the linker? And how to compensate? You're probably one of the two ppl in the world who know OptLink ...

I'd first look at the contents of the .obj file, and see if that is what is expected. I'd also check the optlink instructions http://www.digitalmars.com/ctg/ctgLinkSwitches.html#alignment
as there are quite a lot of switches that offer a great deal of control over the linking process.

> Also: are dmd obj files compatible with any other linker?

Any linker that supports the Microsoft OMF format. I know Microsoft linkers dropped support for it when they went to 32 bits, but I am not very familiar with other linkers. Pharlap did, but I think they went out of business.

Sean Kelly wrote:
> Thomas Kuehne wrote:
>> Every non-trivial module contains (numbers are for Linux)
>> _D5module7__arrayZ
>> 23 bytes code, 19 bytes stringtab, 18 bytes symtab
>>
>> _D5module8__assertFiZv
>> 24 bytes code, 23 bytes stringtab, 18 bytes symtab
> 
> These are the outstanding problem for exposing templates from library code.  And I don't understand why they are generated, since it seems like the code will be identical for each instance generated.  Couldn't they just have a static definition in the runtime?

In their current form they're not identical for each module, for the simple reason that the code (after linking) has the reference to the module name string hardcoded.
For two extra instructions per call that could be avoided, though at that point you might as well just call _d_assert/_d_arraybounds directly instead of using an intermediary function...

Frits van Bommel wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> kris wrote:
>>>
>>>> There's no real surprise that this would happen, but it's the actual difference that is cause for a little concern -- it appears that each module consumes 512 bytes minimum. This may actually be a linker thing, but perhaps not?
>>>
>>>
>>>
>>> The way to see what's in an object file is to run obj2asm on it. It'll show exactly what's submitted to the linker.
>>>
>>
>> I'm aware of that, thanks.
>>
>> Do you think you could comment on why it might be the linker?
> 
> 
> Suggesting you look at what's submitted to the linker doesn't necessarily imply the linker is the cause. If it receives object files with more data in it (generated by the compiler) and dutifully links them, the output is still bigger ;).

That's right. But I'd already looked at the obj file content, and subsequently discounted it :p