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