www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Executable size

reply Frank Benoit <keinfarbton googlemail.com> writes:
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?
May 07 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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?



Is this compiled all-at-once or with each object compiled separately?
May 07 2008
next sibling parent Tower Ty <tytower hotmail.com.au> writes:
Robert Fraser 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?



 Is this compiled all-at-once or with each object compiled separately?




Jar files were introduced with JDK1.1 and are based on the Zip format so they
are compressed somewhat
May 08 2008
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Robert Fraser Wrote:

 Is this compiled all-at-once or with each object compiled separately?



all-at-once.
Would you expect it, to be a big difference?
May 08 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Frank Benoit wrote:

 Robert Fraser Wrote:

 Is this compiled all-at-once or with each object compiled separately?



 all-at-once.
 Would you expect it, to be a big difference?



In the other direction. Gregor mentioned that if it's compiled 
separately a bunch of redundant type information is included. He cited 
some library (the old DWT maybe... too lazy to look up the post) that 
ballooned from ~5MB to ~17MB when each file was compile separately.
May 09 2008
parent reply Gregor Richards <Richards codu.org> writes:
Robert Fraser wrote:

 Frank Benoit wrote:

 Robert Fraser Wrote:

 Is this compiled all-at-once or with each object compiled separately?



 all-at-once.
 Would you expect it, to be a big difference?



 In the other direction. Gregor mentioned that if it's compiled 
 separately a bunch of redundant type information is included. He cited 
 some library (the old DWT maybe... too lazy to look up the post) that 
 ballooned from ~5MB to ~17MB when each file was compile separately.



If you compile them separately, the /library/ will be larger, but 
resultant /binaries/ will be smaller.

  - Gregor Richards
May 09 2008
parent torhu <no spam.invalid> writes:
Gregor Richards wrote:

 Robert Fraser wrote:

 Frank Benoit wrote:

 Robert Fraser Wrote:

 Is this compiled all-at-once or with each object compiled separately?



 all-at-once.
 Would you expect it, to be a big difference?



 In the other direction. Gregor mentioned that if it's compiled 
 separately a bunch of redundant type information is included. He cited 
 some library (the old DWT maybe... too lazy to look up the post) that 
 ballooned from ~5MB to ~17MB when each file was compile separately.



 If you compile them separately, the /library/ will be larger, but 
 resultant /binaries/ will be smaller.



I tried this with my dwt project, using dmd on Windows.  When dwt is 
compiled with oneatatime=yes, my app becomes 1.6 MB.  Without, it's 2.4 
MB.  That's a 50% increase in size.  The library itself is 6.0 MB in 
either case, built with '-O -release'.

When I was still using the old DWT, my app was 1 MB.  Since the old dwt 
was built with bud, all files were compiled at once, so I guess it could 
have been noticably smaller if built one file at a time.
May 10 2008
prev sibling next sibling parent reply terranium <spam here.lot> writes:
Frank Benoit Wrote:


 A compiled DWT app as .exe is about 7 MB and using JFace 14 MB.
 



Whoa. Poseidon uses DWT and it's a *little* bit smaller.
May 08 2008
parent John Reimer <terminal.node gmail.com> writes:
On Thu, 08 May 2008 10:15:55 -0400, terranium wrote:


 Frank Benoit Wrote:
 
 

 A compiled DWT app as .exe is about 7 MB and using JFace 14 MB.
 
 







Poseidon is still using the old dwt.  Size has always been a concern of 
mine with dwt (new).  I hope we can get this one figured out.

-JJR
May 08 2008
prev sibling next sibling parent reply novice2 <sorry noem.ail> writes:
 The compiled code for Java SWT+JFace
 swt.jar   1.9  MB
 jface.jar 0.95 MB
 
 A compiled DWT app as .exe is about 7 MB and using JFace 14 MB.
May 08 2008
parent John Reimer <terminal.node gmail.com> writes:
On Thu, 08 May 2008 10:53:38 -0400, novice2 wrote:


 The compiled code for Java SWT+JFace
 swt.jar   1.9  MB
 jface.jar 0.95 MB
 
 A compiled DWT app as .exe is about 7 MB and using JFace 14 MB.
 



 exe - you can. so you should add Java Runtime (JRE folder) size




Good point.

-JJR
May 08 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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
May 08 2008
next sibling parent reply terranium <spam here.lot> writes:
Steven Schveighoffer Wrote:


 The built executables include tango/phobos, so you cannot compare that 
 version, unless you want to add in the java runtime jar files :)
May 08 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"terranium" wrote

 Steven Schveighoffer Wrote:


 The built executables include tango/phobos, so you cannot compare that
 version, unless you want to add in the java runtime jar files :)






Why not?  Here is an example of tango:

-rw-rw-r-- 1 steves steves 6273270 May  8 11:07 libtango-user-dmd.a
-rw-rw-r-- 1 steves steves 1212253 May  8 11:06 libtango-user-dmd.a.gz

6.3MB -> 1.2MB

By that ratio, 14MB should go down to 2.6MB.

Executable code is very compressable, because it's not very random.

-Steve
May 08 2008
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
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
May 08 2008
parent terranium <spam here.lot> writes:
John Reimer Wrote:


 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



So how big is size of compiled DWT library?
May 09 2008
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Fri, 09 May 2008 06:19:15 -0400, terranium wrote:


 John Reimer Wrote:
 

 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



 So how big is size of compiled DWT library?



I have 11Mb for my .a library.
May 09 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
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 



I doubt it. ALl of Tango compiled I think is like 7MB, and I doubt DWT i 
using more than a fraction of Tango.
May 09 2008
prev sibling next sibling parent reply Neal Alexander <WQEQWEUQY HOTMAIL.COM> writes:
Steven Schveighoffer wrote:

 Once D is natively using DLL/.so to store the runtime, executable sizes 
 should go way down.
 
 -Steve 
 
 



system. Even a lot of MSVC++ programs end up being distributed with 
local copies of the MSVCRT runtime just to be sure that people dont have 
broken versions in their system folder.

People need the option to statically or dynamically link the runtime 
based on their specific project needs. Statically linking the core 
runtime is best unless your project is split across multiple D 
executable files/DLLs.

In any case, D's runtime bloat is pretty much on par with OCaml and 
Haskell/GHC(SplitObjs).


DWT seems pretty bloated, but its probably half the size of GTK haha.
May 09 2008
parent e-t172 <e-t172 akegroup.org> writes:
Jesse Phillips a écrit :

 Actually this is one area that makes it more difficult to adopt, packages 
 relying on shared libraries conflicting with others that require a 
 different version. Where most apps in windows will just carry the needed 
 bloat to just make it work. In any case package managers have been a 
 great help but don't fix it entirely.



That's why there is a Unix convention for library version numbers 
(x.y.z). If there is a breaking change, then the new library is put into 
another package. This way the new library and the old library happily 
cohabit on the system. Software that use the old library will have the 
old library, and software that use the new library will have the new 
library.
May 10 2008
prev sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Fri, 09 May 2008 15:24:20 -0700, Neal Alexander wrote:


 Steven Schveighoffer wrote:

 Once D is natively using DLL/.so to store the runtime, executable sizes
 should go way down.
 
 -Steve
 
 



 system. Even a lot of MSVC++ programs end up being distributed with
 local copies of the MSVCRT runtime just to be sure that people dont have
 broken versions in their system folder.
 
 People need the option to statically or dynamically link the runtime
 based on their specific project needs. Statically linking the core
 runtime is best unless your project is split across multiple D
 executable files/DLLs.
 
 In any case, D's runtime bloat is pretty much on par with OCaml and
 Haskell/GHC(SplitObjs).
 
 
 DWT seems pretty bloated, but its probably half the size of GTK haha.



On a linux system shared libraries are easy to keep correct (if packaged 
correctly). This is merely a flaw of the OS you're running. :) I couldn't 
resist.

Actually this is one area that makes it more difficult to adopt, packages 
relying on shared libraries conflicting with others that require a 
different version. Where most apps in windows will just carry the needed 
bloat to just make it work. In any case package managers have been a 
great help but don't fix it entirely.
May 09 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Frank Benoit wrote:

Afaik jar is a zip without using compression.





-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 25 2008
parent terranium <spam here.lot> writes:
Does switching to gdc helps with exe size?
May 28 2008