Executable size

John Reimer terminal.node at gmail.com
Thu May 8 19:51:30 PDT 2008


On Thu, 08 May 2008 11:00:15 -0400, Steven Schveighoffer wrote:

> "Frank Benoit" wrote
>> The compiled code for Java SWT+JFace
>> swt.jar   1.9  MB
>> jface.jar 0.95 MB
>>
>> I would expect that this code ported to D should result in a smaller
>> amount of code. Java hold all the reflection information, D not. Afaik
>> jar is a zip without using compression.
>> A compiled DWT app as .exe is about 7 MB and using JFace 14 MB.
>>
>> Why is that? How can it be done better?
> 
> If you want to compare apples to apples:
> 
> unjar the swt and jface files (this will make a directory structure,
> find out how much space that takes up). Jar files are compressed.
> 
> Compile DWT and D JFace into libraries.
> 
> Compare those sizes.
> 
> The built executables include tango/phobos, so you cannot compare that
> version, unless you want to add in the java runtime jar files :)
> 
> D has some reflection information through the typeinfo classes, so I
> would expect the uncompressed sizes to be roughly equivalent.
> 
> Once D is natively using DLL/.so to store the runtime, executable sizes
> should go way down.
> 
> -Steve


DWT also still has many instances of "const" use.  This won't necessarily 
be the cause of such excessive code bloat, but it adds to it.  Also, in 
contrast to the old dwt which integrates many java modules into single D 
modules, our new dwt tries to have a one-to-one module relationship with 
Java SWT (for porting ease).  This MIGHT add an significant load of 
symbols per module to the DWT project (module info).  I'd love to explore 
ways to shrink this down, but I think that would mean compromising future 
porting ease.  It would certainly mean that we'd have to forgo some Java-
isms.  

I guess the dwt port will have to become a exercise in good judgement/
practicality: 1) should we specialize it for the D language, shrink it 
noticeabley, and optimize it further (and forgo the simplicity of porting 
future SWT version updates); or should we keep direct one-to-one module 
consistancy with SWT so that we can track the updates (meaning fairly 
quick DWT version upgrades, but severe and more severe bloat).

Obviously, as already Steven mentions, another option (eventually) would 
be to find a way to turn DWT/Jface into a shared library.  But, at 
present, this appears to be difficult task.

-JJR




More information about the Digitalmars-d mailing list