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!

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

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"

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.

Thank you for all of the great answers, everyone!

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) ?

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