Jump to page: 1 2
Thread overview
Programs in D are huge
Aug 16, 2022
Diego
Aug 16, 2022
user1234
Aug 16, 2022
Dennis
Aug 16, 2022
Salih Dincer
Aug 17, 2022
Diego
Aug 17, 2022
Ali Çehreli
Aug 18, 2022
Diego
Aug 18, 2022
IGotD-
Aug 18, 2022
rikki cattermole
Aug 19, 2022
Patrick Schluter
Aug 19, 2022
bauss
Aug 19, 2022
IGotD-
Aug 19, 2022
IGotD-
August 16, 2022

Hello everyone,

I'm a Java programmer at work but i'm learning D for pleasure. I'm reading The D Programming Language by Ali Çehreli.

I noticed that DMD creates very huge executable, for example an empty program:

empty.d:

void main() {
	
}

after a compilation with these flags dmd -de -w empty.d i have an executable of 869KiB
It seams huge in my opinion for an empty program

What are the best practices to reduce the size?

August 16, 2022

On Tuesday, 16 August 2022 at 08:25:18 UTC, Diego wrote:

>

Hello everyone,

I'm a Java programmer at work but i'm learning D for pleasure. I'm reading The D Programming Language by Ali Çehreli.

I noticed that DMD creates very huge executable, for example an empty program:

empty.d:

void main() {
	
}

after a compilation with these flags dmd -de -w empty.d i have an executable of 869KiB
It seams huge in my opinion for an empty program

What are the best practices to reduce the size?

This is normal, by default you have plenty of typeinfo (static data allowing dynamic introspection), code located in implicit import object.d, the runtime (e.g code for the GC).

You can really get rid of that, excepted using -betterC, but you see all the stuff that make the default main program big will actually be useful in a real program.

It's just that D is not as much "pay as you go" as that, for now.

August 16, 2022

On Tuesday, 16 August 2022 at 08:25:18 UTC, Diego wrote:

>

It seams huge in my opinion for an empty program

What are the best practices to reduce the size?

The problem is that the druntime, the run time library needed to support many D features, is large and linked in its entirety by default. The linker could strip unused functions, but even in an empty program, a lot is done before main that pulls in most of it:

  • initializing floating point settings, signal handlers, stdout and stderr
  • parsing --DRT command line options for configuring the Garbage Collector
  • running module constructors / unit tests

There is a goal to make druntime more 'pay as you go' so these things only happen when they're needed, but progress is slow. In the mean time, if you can live without a lot of D features that require the runtime, you can use -betterC:

https://dlang.org/spec/betterc.html

With the LDC2 compiler, you can use --link-defaultlib-shared, so your program dynamically links with the run time library. This doesn't help for a single D program, but multiple D programs can reuse a single shared library.

Finally, you could look at customized versions of the runtime, such as Light Weight D Runtime: https://github.com/hmmdyl/LWDR

August 16, 2022

On Tuesday, 16 August 2022 at 08:25:18 UTC, Diego wrote:

>

after a compilation with these flags dmd -de -w empty.d i have an executable of 869KiB
It seams huge in my opinion for an empty program

What are the best practices to reduce the size?

If compile speed and verbose error codes are not important, use ldc2 with the -O1 parameter. There is also strip for Linux. For example, a simple program:

LCD2+strip: 138.5KB.
DMD: 1.9 MB.

SDB@79

August 16, 2022

On 8/16/22 4:25 AM, Diego wrote:

>

Hello everyone,

I'm a Java programmer at work but i'm learning D for pleasure. I'm reading The D Programming Language by Ali Çehreli.

I noticed that DMD creates very huge executable, for example an empty program:

empty.d:

void main() {

}

after a compilation with these flags dmd -de -w empty.d i have an executable of 869KiB
It seams huge in my opinion for an empty program

What are the best practices to reduce the size?

By default (but changing in some cases), D links the standard library in statically. This means that every D executable has a copy of the library (at least the used functions).

If you use C for a comparison, you have to include the C library size as well when comparing. On my system, libc is 2MB.

You can reduce size by using dynamic linking, but the drawback is that then you have to ensure the library exists on the target system in order to run.

If you are shipping a package with lots of D binaries it might make sense to do this, but for one-offs, probably not.

-Steve

August 17, 2022

Thank you to everyone,

I'm writing a little terminal tool, so i think -betterC is the best and simple solution in my case.

August 17, 2022
On 8/17/22 09:28, Diego wrote:

> I'm writing a little terminal tool, so i think `-betterC` is the best
> and simple solution in my case.

It depends on what you mean with terminal tool bun in general, no, full features of D is the most useful option.

I've written a family of programs that would normally be run on the terminal; I had no issues that would warrant -betterC.

Ali

August 18, 2022

On Wednesday, 17 August 2022 at 17:25:51 UTC, Ali Çehreli wrote:

>

On 8/17/22 09:28, Diego wrote:

>

I'm writing a little terminal tool, so i think -betterC is
the best
and simple solution in my case.

It depends on what you mean with terminal tool bun in general, no, full features of D is the most useful option.

I've written a family of programs that would normally be run on the terminal; I had no issues that would warrant -betterC.

Ali

Thank you all,

As suggested from Salih is better to use ldc2 with --link-defaultlib-shared and -O1
Ali, your book is a fluent reading, thank you :)

Diego

August 18, 2022
On Wednesday, 17 August 2022 at 17:25:51 UTC, Ali Çehreli wrote:
> On 8/17/22 09:28, Diego wrote:
>
> > I'm writing a little terminal tool, so i think `-betterC` is
> the best
> > and simple solution in my case.
>
> It depends on what you mean with terminal tool bun in general, no, full features of D is the most useful option.
>
> I've written a family of programs that would normally be run on the terminal; I had no issues that would warrant -betterC.
>
> Ali

BetterC means no arrays or strings library and usually in terminal tools you need to process text. Full D is wonderful for such task but betterC would be limited unless you want to write your own array and string functionality.
August 19, 2022
On 19/08/2022 4:56 AM, IGotD- wrote:
> BetterC means no arrays or strings library and usually in terminal tools you need to process text. Full D is wonderful for such task but betterC would be limited unless you want to write your own array and string functionality.

Unicode support in Full D isn't complete.

There is nothing in phobos to even change case correctly!

Both are limited if you care about certain stuff like non-latin based languages like Turkic.
« First   ‹ Prev
1 2