www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Programs in D are huge

reply Diego <diego.marcolungo gmail.com> writes:
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?
Aug 16 2022
next sibling parent user1234 <user1234 12.de> writes:
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.
Aug 16 2022
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
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
Aug 16 2022
prev sibling next sibling parent Salih Dincer <salihdb hotmail.com> writes:
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
Aug 16 2022
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Aug 16 2022
parent reply Diego <diego.marcolungo gmail.com> writes:
Thank you to everyone,

I'm writing a little terminal tool, so i think `-betterC` is the 
best and simple solution in my case.
Aug 17 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Aug 17 2022
next sibling parent Diego <diego.marcolungo gmail.com> writes:
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
Aug 18 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
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.
Aug 18 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Aug 18 2022
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 18 August 2022 at 17:15:12 UTC, rikki cattermole 
wrote:

 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.


A general toupper/tolower for Unicode is doomed to fail. As 
already mentioned Turkish has its specificity, but other 
languages also have traps. In Greek toupper/tolower are not 
reversible i.e. `x.toupper.tolower == x` is not guaranteed . Some 
languages have 1 codepoint input and 2 codepoints as result 
(German ß becomes SS in most cases, capital ẞ is not the right 
choice in most cases).
etc. etc.
Aug 18 2022
parent reply bauss <jacobbauss gmail.com> writes:
On Friday, 19 August 2022 at 06:34:19 UTC, Patrick Schluter wrote:

 On Thursday, 18 August 2022 at 17:15:12 UTC, rikki cattermole 
 wrote:

 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.


 A general toupper/tolower for Unicode is doomed to fail. As 
 already mentioned Turkish has its specificity, but other 
 languages also have traps. In Greek toupper/tolower are not 
 reversible i.e. `x.toupper.tolower == x` is not guaranteed . 
 Some languages have 1 codepoint input and 2 codepoints as 
 result (German ß becomes SS in most cases, capital ẞ is not the 
 right choice in most cases).
 etc. etc.


That's why you should implementat formatting providers for 
languages that handle such things.


methods such as ToString, ToLower etc. which will correctly 
handle specific "cultures"

It's one thing D really misses, but is really hard to implement 
when it wasn't thought of to begin with. It should have been 
implemented alongside functions that may change between languages 
and cultures.
Aug 19 2022
parent IGotD- <nise nise.com> writes:
On Friday, 19 August 2022 at 11:18:48 UTC, bauss wrote:

 It's one thing D really misses, but is really hard to implement 
 when it wasn't thought of to begin with. It should have been 
 implemented alongside functions that may change between 
 languages and cultures.


I guess we have another task for Phobos v2.
Aug 19 2022
prev sibling parent IGotD- <nise nise.com> writes:
On Thursday, 18 August 2022 at 17:15:12 UTC, rikki cattermole 
wrote:

 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.


I think full D is fine for terminal programs. What you commonly 
do is tokenize text, remove white space, convert text to numbers 
etc. The D library is good for these tasks. Rewrite all this for 
betterC would be a tedious tak
Aug 19 2022