dmd makes D appear slow

[Shachar Shemesh via Digitalmars-d]

On 01/06/15 18:40, Steven Schveighoffer wrote:
> On 5/30/15 2:38 PM, Shachar Shemesh wrote:
>
> So given that a compiler actually *works* (i.e. produces valid
> binaries), is speed of compilation better than speed of execution of the
> resulting binary?
There is no answer to that question.

During development stage, there are many steps that have "compile" as a 
hard start/end barrier (i.e. - you have to finish a task before compile 
start, and cannot continue it until compile ends). During those stages, 
the difference between 1 and 10 minute compile is the difference between 
1 and 10 bugs solved in a day. It is a huge difference, and one it is 
worth sacrificing any amount of run time efficiency to pay, assuming 
this is a tradeoff you can later make.

Then again, when a release build is being prepared, the difference 
becomes moot. Even your "outrageous" figures become acceptable, so long 
as you can be sure that no bugs pop up in this build that did not exist 
in the non-optimized build.

Then again, please bear in mind that our product is somewhat atypical. 
Most actual products in the market are not CPU bound on algorithmic 
code. When that's the case, the optimization stage (beyond the most 
basic inlining stuff) will rarely give you 20% overall speed increase. 
When your code performs a system call every 40 assembly instructions, 
there simply isn't enough room for the optimizer to work its magic.

One exception to that above rule is where it hurts. Benchmarks, 
typically, do rely on algorithmic code to a large extent.

Shachar