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.
 
 
Whoa. Poseidon uses DWT and it's a *little* bit smaller.
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.
 
but big diff: you can't run your jar in any windows computer. but with exe - you can. so you should add Java Runtime (JRE folder) size
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.
 
but big diff: you can't run your jar in any windows computer. but with 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 :)
 
do you think zip can deflate 14MB of executable code to 3MB?
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 :)
do you think zip can deflate 14MB of executable code to 3MB?
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 reply 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
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 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 
 
 
Not many users are going to have the D runtime DLL present on their 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 reply 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
 
 
Not many users are going to have the D runtime DLL present on their 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
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 next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
terranium Wrote:

 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.
Yes, indeed. I wonder if UPX was used. What is the difference? Is it just that the old DWT uses less modules?
May 08 2008
next sibling parent reply terranium <spam here.lot> writes:
Frank Benoit Wrote:

 Whoa. Poseidon uses DWT and it's a *little* bit smaller.
Yes, indeed. I wonder if UPX was used. What is the difference? Is it just that the old DWT uses less modules?
Does it use old DWT? And what are you writing I wonder? A photoshop?
May 09 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
terranium schrieb:
 Frank Benoit Wrote:
 
 Whoa. Poseidon uses DWT and it's a *little* bit smaller.
Yes, indeed. I wonder if UPX was used. What is the difference? Is it just that the old DWT uses less modules?
Does it use old DWT? And what are you writing I wonder? A photoshop?
Poseidon uses the SWT port from Shawn. I am talking about a simple test apps. The structure of SWT make every app to pull in a big part of the SWT lib.
May 09 2008
prev sibling parent reply yidabu <yidabu.spam gmail.com> writes:
On Thu, 08 May 2008 14:47:21 -0400
Frank Benoit <keinfarbton googlemail.com> wrote:

 terranium Wrote:
 
 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.
Yes, indeed. I wonder if UPX was used. What is the difference? Is it just that the old DWT uses less modules?
I use dsss to build a simple jface program (just one module), it takes more than 800 obj files (modules), the executable size is 15 MB. ( dwt-win svn, dwt-addons svn). Does all 800 modules must compile in the simple jface program ? btw, seems impossible to build a jface program by dmd directly. -- yidabu <yidabu.spam gmail.com> http://www.dsource.org/projects/dwin D -(D Chinese): http://www.d-programming-language-china.org/ http://bbs.d-programming-language-china.org/ http://dwin.d-programming-language-china.org/ http://scite4d.d-programming-language-china.org/
May 12 2008
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
yidabu schrieb:
 I use dsss to build a simple jface program (just one module), it takes more
than 800 obj files (modules), the executable size is 15 MB. ( dwt-win svn,
dwt-addons svn). 
 
 Does all 800 modules must compile in the simple jface program ? 
 
 btw, seems impossible to build a jface program by dmd directly.
 
You will need a response file to pass the arguements to DMD. The windows comand line is restricted to 8192 characters. The build tools like DSSS/bud should do this by default.
May 12 2008
parent reply Pragma <eric.t.anderton gmail.com> writes:
Frank Benoit Wrote:

 yidabu schrieb:
 I use dsss to build a simple jface program (just one module), it takes more
than 800 obj files (modules), the executable size is 15 MB. ( dwt-win svn,
dwt-addons svn). 
 
 Does all 800 modules must compile in the simple jface program ? 
 
 btw, seems impossible to build a jface program by dmd directly.
 
You will need a response file to pass the arguements to DMD. The windows comand line is restricted to 8192 characters. The build tools like DSSS/bud should do this by default.
Also, if you opt to not to link in the DWT library, and use the DWT sources directly, rebuild/bud should mange the .obj dependencies for you. That should result in a smaller executable size, at the cost of a longer compile. - Pragma
May 12 2008
parent yidabu <yidabu.spam gmail.com> writes:
On Mon, 12 May 2008 10:59:21 -0400
Pragma <eric.t.anderton gmail.com> wrote:

 Frank Benoit Wrote:
 
 yidabu schrieb:
 I use dsss to build a simple jface program (just one module), it takes more
than 800 obj files (modules), the executable size is 15 MB. ( dwt-win svn,
dwt-addons svn). 
 
 Does all 800 modules must compile in the simple jface program ? 
 
 btw, seems impossible to build a jface program by dmd directly.
 
You will need a response file to pass the arguements to DMD. The windows comand line is restricted to 8192 characters. The build tools like DSSS/bud should do this by default.
Also, if you opt to not to link in the DWT library, and use the DWT sources directly, rebuild/bud should mange the .obj dependencies for you. That should result in a smaller executable size, at the cost of a longer compile. - Pragma
I link in the dwt.lib and dwtx.lib (added to sc.ini), to build ApplicationWindow based jface program by dmd directly: dmd test.d -L/SUBSYSTEM:windows:5 test.exe cause unhandled runtime exception: tango.core.Exception.IllegalElementException: Attempt to include invalid key _in Collection -- yidabu <yidabu.spam gmail.com> http://www.dsource.org/projects/dwin D -(D Chinese): http://www.d-programming-language-china.org/ http://bbs.d-programming-language-china.org/ http://dwin.d-programming-language-china.org/ http://scite4d.d-programming-language-china.org/
May 12 2008
prev sibling next sibling parent reply terranium <spam here.lot> writes:
Neal Alexander Wrote:

 Steven Schveighoffer wrote:
 Once D is natively using DLL/.so to store the runtime, executable sizes 
 should go way down.
 
 -Steve 
 
 
In any case, D's runtime bloat is pretty much on par with OCaml and Haskell/GHC(SplitObjs).
I don't believe D runtime can make any bloat, even whole Phobos is 1MB - how it can become 14MB?
May 10 2008
parent Neal Alexander <WQEQWEUQY HOTMAIL.COM> writes:
terranium wrote:
 Neal Alexander Wrote:
 
 Steven Schveighoffer wrote:
 Once D is natively using DLL/.so to store the runtime, executable sizes 
 should go way down.

 -Steve 
In any case, D's runtime bloat is pretty much on par with OCaml and Haskell/GHC(SplitObjs).
I don't believe D runtime can make any bloat, even whole Phobos is 1MB - how it can become 14MB?
Its not Phobos. "Hello world" in D, OCaml, and haskell/ghc are all around 300kb (+-100k) DWT or GTK can easily add 10mb to a distro. There may be D bindings for lightweight GUI toolkits like FLTK (http://www.fltk.org/) or something - i dunno, i never bothered checking. Even if theres no bindings, you can always use some WYSIWYG tool to generate a C skeleton to plug your D code into. And on a side note: last time i native compiled a quick graph visualization GUI in java the dependencies were like 50mb heh.
May 11 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Frank Benoit wrote:
Afaik jar is a zip without using compression.
A jar is simply a zip file, it can be with or without 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