Inherent code performance advantages of D over C?

[Jason den Dulk]

On Saturday, 7 December 2013 at 00:09:01 UTC, John Colvin wrote:
> On Friday, 6 December 2013 at 23:56:39 UTC, H. S. Teoh wrote:
>>
>> It would be nice to decouple Phobos modules more. A *lot* more.
>
> Why? I've seen this point made several times and I can't 
> understand why this is an important concern.
>
> I see the interplay between phobos modules as good, it saves 
> reinventing the wheel all over the place, making for a smaller, 
> cleaner standard library.
>
> Am I missing something fundamental here?

On the introduction page of the Phobos documentation, as part of 
it's philosophy, it states

"Classes should strive to be independent of one another
     It's discouraging to pull in a megabyte of code bloat by just 
trying to read a file into an array of bytes. Class independence 
also means that classes that turn out to be mistakes can be 
deprecated and redesigned without forcing a rewrite of the rest 
of the class library."

(This can also apply to functions, templates and modules).

Currently, Phobos does exactly that. It pulls in a lot of bloat 
to perform trivial tasks, and it is discouraging. More 
importantly it is difficult to  isolate any part of Phobos. When 
trying to avoid any part of Phobos because of bugginess or 
inefficiency, I find it next to impossible because chances are, 
it will be used by some other part of Phobos.

I am speculating here, but I imagine that maintaining and 
debugging Phobos must be a nightmare. Can anybody speak from 
experience on this?

One think I have discovered is that Phobos introduces "junk code" 
into executables. One time I did an experiment. I copied the bits 
of Phobos that my program used into a separate file and imported 
that instead of the Phobos modules. The resultant executable was 
half the size (using -release, -inline, -O and "strip" in both 
cases). For some reason, Phobos was adding over 250KB of junk 
code that strip could not get rid of.

Regards
Jason