Some thing as simple as:

void main ()
{
}

generates a 75kb executable with dmd 1.018 using the following line: dmd -O -release test.d

Does anybody know why this happens? The one thing that prevents me from using D is the large size of the generated files.

Here are the sizes of the files generated by the compiler:
test.obj - 395 bytes
test.map - 2390 bytes
test.exe - 76828 bytes

Is Microsoft's OMF naturally large? Are runtime type checks to blame?

If anybody could help or explain this to me, it would be greatly appreciated.

This is primarily because the current setup has the exututabe linked against a static runtime library. I am not sure about Windows, but on most platforms the C and C++ runtime libraries are dynamically linked, which makes the executables a lot smaller.

The test.obj is about the size your executable would be with static linking to the runtime.

There is no reason why you couldn't compile a dynamic version of the library, and link to that instead (and in fact, several people on this mailing list have done it already - use the search)., although this may be somewhat more complicated on Windows than on Mac/Unix

rpgfan3233 Wrote:
> Some thing as simple as:
> 
> void main ()
> {
> }
> 
> generates a 75kb executable with dmd 1.018 using the following line: dmd -O -release test.d
> 
> Does anybody know why this happens? The one thing that prevents me from using D is the large size of the generated files.
> 
> Here are the sizes of the files generated by the compiler:
> test.obj - 395 bytes
> test.map - 2390 bytes
> test.exe - 76828 bytes
> 
> Is Microsoft's OMF naturally large? Are runtime type checks to blame?
> 
> If anybody could help or explain this to me, it would be greatly appreciated.

rpgfan3233 schrieb:
> Does anybody know why this happens? The one thing that prevents me from using D is the large size of the generated files.
70 KB is nothing compared to several MBs (which is the case for many extensive applications)
You use an executable packer if you want the size to be reduced nevertheless.

But 70k is an impressive overhead for an empty main function... And how will an executable packer help when most of them are incompatible with DMD?
Hoenir Wrote:
> rpgfan3233 schrieb:
> > Does anybody know why this happens? The one thing that prevents me from using D is the large size of the generated files.
> 70 KB is nothing compared to several MBs (which is the case for many
> extensive applications)
> You use an executable packer if you want the size to be reduced
> nevertheless.

"rpgfan3233" <rpgfan3233@gmail.com> wrote in message news:f7qlnl$goj$1@digitalmars.com...
> generates a 75kb executable with dmd 1.018 using the following line: dmd -O -release test.d
>
> Does anybody know why this happens? The one thing that prevents me from using D is the large size of the generated files.

The one thing?  The one, single, motivating factor for you to not use D is because an empty executable is 70KB?  Unless you're developing for an embedded system, or competing in the 64k demo competition, there's no need for executables to be very, very small.

This 70KB is largely due to the runtime type info which is included (and necessary) for most of the runtime to use.  This also includes the garbage collector.

This is pretty much a constant overhead.  You can think of the size of the EXE as a line ax + b, where b is 70K and x is the amount of user code.  Have you tried building a larger program?  You'll end up with EXEs very similar in size to those written in other languages.

Tristam MacDonald wrote:
> But 70k is an impressive overhead for an empty main function... And how will an executable packer help when most of them are incompatible with DMD?

UPX works with DMD just fine.  I use it with my own code.
http://upx.sourceforge.net/

To see how much difference it'd make, I wrote this empty program:
module empty;
void main () {}

With DMD 1.018/Tango/WinXP it compiled to 102,940 bytes (100.5 KB).
I ran: upx -9 empty.exe
It packed down to 44,032 bytes (43 KB).

I consider that a pretty nice improvement.  :)

-- Chris Nicholson-Sauls

"Tristam MacDonald" <swiftcoder@gmail.com> wrote in message news:f7r3rm$16ig$1@digitalmars.com...
> But 70k is an impressive overhead for an empty main function... And how will an executable packer help when most of them are incompatible with DMD?

The only executable packers I know of work directly with EXEs.  So why should they care what compiler was used?

Stewart. 

Having searched the newsgroup, I had only found reports of UPX not working with DMD produced executables. I guess the bugs have been fixed in one or the other since the last discussion.

Chris Nicholson-Sauls Wrote:
> Tristam MacDonald wrote:
> > But 70k is an impressive overhead for an empty main function... And how will an executable packer help when most of them are incompatible with DMD?
> 
> UPX works with DMD just fine.  I use it with my own code. http://upx.sourceforge.net/
> 
> To see how much difference it'd make, I wrote this empty program:
> module empty;
> void main () {}
> 
> With DMD 1.018/Tango/WinXP it compiled to 102,940 bytes (100.5 KB).
> I ran: upx -9 empty.exe
> It packed down to 44,032 bytes (43 KB).
> 
> I consider that a pretty nice improvement.  :)
> 
> -- Chris Nicholson-Sauls

Stewart Gordon wrote:
> "Tristam MacDonald" <swiftcoder@gmail.com> wrote in message news:f7r3rm$16ig$1@digitalmars.com...
>> But 70k is an impressive overhead for an empty main function... And how will an executable packer help when most of them are incompatible with DMD?
> 
> The only executable packers I know of work directly with EXEs.  So why should they care what compiler was used?
> 
> Stewart.

They use ridiculously gross tricks that can cause the environment at entry to be slightly askew.

 - Gregor Richards

Tristam MacDonald schrieb:
> But 70k is an impressive overhead for an empty main function... And how will an executable packer help when most of them are incompatible with DMD?
MEW 11.2 works flawlessly.
And 70k is really nothing in these days.