www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Small program producing binary with large filesize

reply Dan Barbarito <dan barbarito.me> writes:
Hi all,

I am starting to write a command line tool. So far it is a small 
(feature-wise) program but the file size is scaring me. It's 
already 13 megabytes, but I would expect it to be much smaller. 
Is it because I'm using 3 libraries so far? The libraries are: 
mir, vibe.d, and d2sqlite3. Would using these libraries be 
causing this file size?

The code can be found here 
(http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone 
wants to take a look. I am simply running "dub build" to build 
the binary. I tried running "dub build --build=release" but that 
didn't effect the file size too much.

Thanks!
Jul 31 2018
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/31/18 11:19 AM, Dan Barbarito wrote:

 Hi all,
 
 I am starting to write a command line tool. So far it is a small 
 (feature-wise) program but the file size is scaring me. It's already 13 
 megabytes, but I would expect it to be much smaller. Is it because I'm 
 using 3 libraries so far? The libraries are: mir, vibe.d, and d2sqlite3. 
 Would using these libraries be causing this file size?
 
 The code can be found here 
 (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone wants to 
 take a look. I am simply running "dub build" to build the binary. I 
 tried running "dub build --build=release" but that didn't effect the 
 file size too much.
 
 Thanks!


D is statically linked, so the file size includes ALL the libraries 
(except for the C dynamic ones). Comparing this to C binaries, which are 
generally only linked dynamically, you will see much larger sizes.

-Steve
Jul 31 2018
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Tuesday, 31 July 2018 at 15:19:19 UTC, Dan Barbarito wrote:

 Hi all,

 I am starting to write a command line tool. So far it is a 
 small (feature-wise) program but the file size is scaring me. 
 It's already 13 megabytes, but I would expect it to be much 
 smaller. Is it because I'm using 3 libraries so far? The 
 libraries are: mir, vibe.d, and d2sqlite3. Would using these 
 libraries be causing this file size?

 The code can be found here 
 (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone 
 wants to take a look. I am simply running "dub build" to build 
 the binary. I tried running "dub build --build=release" but 
 that didn't effect the file size too much.

 Thanks!


If you use LDC, release build and their full LTO (-flto=full), 
the resulting binary should get smaller.

DFLAGS="-flto=full" dub build --compiler=ldc -b release

As an example, dlang-tour is 53M in debug build with DMD, but 
with LTO + release + ldc it gets down to 6.2M.

You also get a smaller build, if instead of using all of Vibe.d, 
you only use the subset of components you actually use, e.g.

dependency "vibe-d:web" version="~>0.8"
Jul 31 2018
prev sibling parent reply Jacob Shtokolov <jacob.100205 gmail.com> writes:
On Tuesday, 31 July 2018 at 15:19:19 UTC, Dan Barbarito wrote:

 Hi all,

 I am starting to write a command line tool.


Hi!

First, Vibe.d will increase your binary size because it contains 
a lot of unnecessary things inside it. So instead of using the 
entire vibe.d library, you may point dub to specific vibe.d 
parts, like `vibe.d:core`, `vibe.d:http` etc.

If you put the whole vibe.d framework as a dub dependency and use 
it like `import vibe;` the things like mongodb drivers, email 
libraries, redis driver etc. will be linked to your binary as 
well, even if you don't need them.

Second, you need to compile your code in the release mode to cut 
all debug information out of it. Also, you can try to use the 
`strip` command line tool to cut all export symbols if your 
binary is an executable file, not a library. This will reduce the 
size. In some cases a lot.

The third thing is already mentioned: by default, the DMD 
compiler builds and links the code statically. In other words, 
your binary contains parts of the DRuntime and the Phobos 
libraries (those parts that you've used in your program).

This thing helps to distribute compiled binaries without external 
dependencies (except libc and libpthread), because your binary is 
already contains all needed stuff.

If you're not happy with it, you can try to use the LDC compiler, 
which uses the dynamic linking by default. Your binary will be 
really tiny, but in order to execute it, you'll need to have the 
libdruntime.so and libphobos.so installed in your system. This 
may add additional issues if you plan to distribute your program.

Sadly, we still don't have the D runtime libraries installed in 
all popular OSes. Currently only the libc has this privilege 😀

I hope the situation will change in the future.
Aug 01 2018
next sibling parent Dan Barbarito <dan barbarito.me> writes:
Thank you for all of the great answers, everyone!
Aug 01 2018
prev sibling parent reply Prokop Hapala <prokophapala gmail.com> writes:
On Wednesday, 1 August 2018 at 15:58:53 UTC, Jacob Shtokolov 
wrote:

 On Tuesday, 31 July 2018 at 15:19:19 UTC, Dan Barbarito wrote:

 Hi all,

 I am starting to write a command line tool.


 Hi!

 First, Vibe.d will increase your binary size because it 
 contains a lot of unnecessary things inside it. So instead of 
 using the entire vibe.d library, you may point dub to specific 
 vibe.d parts, like `vibe.d:core`, `vibe.d:http` etc.

 If you put the whole vibe.d framework as a dub dependency and 
 use it like `import vibe;` the things like mongodb drivers, 
 email libraries, redis driver etc. will be linked to your 
 binary as well, even if you don't need them.

 Second, you need to compile your code in the release mode to 
 cut all debug information out of it. Also, you can try to use 
 the `strip` command line tool to cut all export symbols if your 
 binary is an executable file, not a library. This will reduce 
 the size. In some cases a lot.

 The third thing is already mentioned: by default, the DMD 
 compiler builds and links the code statically. In other words, 
 your binary contains parts of the DRuntime and the Phobos 
 libraries (those parts that you've used in your program).

 This thing helps to distribute compiled binaries without 
 external dependencies (except libc and libpthread), because 
 your binary is already contains all needed stuff.

 If you're not happy with it, you can try to use the LDC 
 compiler, which uses the dynamic linking by default. Your 
 binary will be really tiny, but in order to execute it, you'll 
 need to have the libdruntime.so and libphobos.so installed in 
 your system. This may add additional issues if you plan to 
 distribute your program.

 Sadly, we still don't have the D runtime libraries installed in 
 all popular OSes. Currently only the libc has this privilege 😀

 I hope the situation will change in the future.



Hi, I was trying with ldc (source ~/dlang/ldc-1.17.0/activate) 
and the size of binary is even worse

dub with dmd 2.89 MB
dub with ldc 3.50 MB

It is very simple program but use derelict-gl3 and derelict-sdl2

I want to link them all dynamically (I don't plan to distribute 
binary any time soon)

What exactly should I specify to make it link dynamcially and 
produce as small binary as possible (without increasing 
compilation time) ?
Oct 21 2019
parent Jacob Shtokolov <jacob.100205 gmail.com> writes:
On Monday, 21 October 2019 at 19:20:04 UTC, Prokop Hapala wrote:

 What exactly should I specify to make it link dynamcially and 
 produce as small binary as possible (without increasing 
 compilation time) ?


Hi! Sorry, just found your response here. In order to force it to 
link dynamically, add these lines to your `dub.json`:

```
"buildTypes": {
     "release-shared": {
         "dflags": ["-link-defaultlib-shared", "-release", "-O3"]
     }
},
"postBuildCommands": [
     "strip ./<my_app>"
]
```

Then build it like that:

```
dub build --build=release-shared --compiler=ldc2
```

Make sure that you replace <my_app> under `postBuildCommands` 
with your own application (binary) name.

The thing is that LDC2 links statically by default, so you have 
to add a few flags to the command line
Nov 10 2019