Inherent code performance advantages of D over C?

[H. S. Teoh]

On Sun, Dec 08, 2013 at 05:19:53AM +0100, Jason den Dulk wrote:
[...]
> I am speculating here, but I imagine that maintaining and debugging
> Phobos must be a nightmare. Can anybody speak from experience on
> this?

Actually, while Phobos does have its warts, it's surprisingly pleasant
to read and maintain, thanks to the readability features of D. I've
found it to be easy to read, and mostly easy to understand. There are
some ugly bits here and there, of course, but compared to, say, glibc,
it's extremely readable for a standard library.

(And FWIW, I'm only a part-time Phobos volunteer, so I'm saying this not
because I've an agenda to defend Phobos, but because I genuinely find it
a pleasant surprise compared to most standard libraries of other
languages that I've seen.)


> 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.
[...]

Yeah, this part bothers me too. Once I hacked up a script (well, a
little D program :P) that disassembles D executables and builds a
reference graph of its symbols. I ran this on a few small test programs,
and was quite dismayed to discover that the mere act of importing
std.stdio (for calling writeln("Hello World");) will introduce symbols
from std.complex into your executable, even though the program has
nothing to do with complex numbers. These symbols are never referenced
from main() (i.e., the reference graph of the std.complex symbols are
disjoint from the subgraph that contains _Dmain), yet they are included
in the executable.

That's why I said that Phobos has a ways to go in terms of modularity
and dependency management. Just because std.complex is used by *some*
obscure bit of code in std.stdio, doesn't mean that it should get pulled
in just because you want to print Hello World. The compiler could also
be a bit smarter about which symbols it emits code for, eliding those
that are never actually referenced in the program.

While my overall D experience has been quite positive, this is one of
the things that I found disappointing.


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler