Bug 24299 – The dmd's command line option "-run" should prefer dynamic linking with the Phobos library by default

Consider the following small program: ```D import std.stdio; void main() { writeln("Hello world!"); } ``` $ which dmd /opt/dmd2-106.0/linux/bin64/dmd $ time dmd -run helloworld.d Hello world! real 0m0.414s $ time dmd -defaultlib=libphobos2.a -run helloworld.d Hello world! real 0m0.414s $ time dmd -defaultlib=libphobos2.so -L-rpath=/opt/dmd2-106.0/linux/lib64 -run helloworld.d Hello world! real 0m0.188s Linking libphobos2.a is more than twice slower than linking libphobos2.so (~414 ms vs. ~188 ms difference on my computer). While theoretically the users can use any fancy command line options, in reality many of them just don't bother. So the performance of just invoking `dmd -run helloworld.d` is bad out of the box. But the compiled binary is immediately discarded after use and there are no downsides to using dynamic linking in this scenario. So linking libphobos2.so would be a more reasonable default configuration specifically for the `-run` option. I suggest to introduce additional sections "[RunEnvironment32]" and "[RunEnvironment64]" in the "dmd.conf" file for the options specifically tailored for the "-run" option. And then binary releases of the DMD compiler could use these sections to provide fast `dmd -run` functionality out of the box.

For comparison, here's a similar test with Go (~143 ms): ```Go package main import "fmt" func main() { fmt.Println("hello world") } ``` $ go version go version go1.21.4 linux/amd64 $ echo " " >> helloworld.go && time go run helloworld.go hello world real 0m0.143s The status quo is that `go run` is significantly faster today and getting closer to its 143 ms should be a target for `dmd -run` as well.

You mention go, but go does statically link everything So you are not matching go in your comparison, you are doing something different to pretend it runs faster The solution is to make phobos less bloated, let us not put the problem under the carpet to pretend it's clean

I think this is actually a pretty good idea. My reservation with dynamic linking in general is that it makes long term functionality and distribution harder; you have a larger sum of data to transfer and have the added difficulty of keeping versions in sync. But indeed, as you say with -run, you aren't keeping it long-term anyway, so it seems there's no downside to it.

(In reply to ryuukk_ from comment #2) > You mention go, but go does statically link everything > > So you are not matching go in your comparison, you are doing something > different to pretend it runs faster The DMD compiler doesn't produce any binary for the end users as a result of using "-run" option, so the choice of static or dynamic linking is a hidden internal implementation detail not visible to the end user. If you think that this kind of "cheating" is unfair to Go, then Go is already "cheating" to an even larger extent by using a custom non-standard format for the object files and relying on its own custom linker to process them. See https://go.googlesource.com/proposal/+/master/design/go13linker.md > The solution is to make phobos less bloated, let us not put the problem > under the carpet to pretend it's clean There's no such thing as "the solution" here. Compilation time can be reduced by doing multiple independent optimizations. Each of them contributes something. Currently there are many low hanging fruits. Even if you succeed in making Phobos less bloated, using dynamic linking instead of static linking will be still beneficial.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/20372 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB