Inherent code performance advantages of D over C?

[Johannes Pfau]

Am Sat, 07 Dec 2013 23:37:08 +0400
schrieb Dmitry Olshansky <dmitry.olsh at gmail.com>:

> > But cross-module inlining can't be done if you have shared libraries
> > cause you can not know if the other module is in a shared library
> > right?
> >
> 
> I've no idea how would compiler do inlining of a shared library 
> internals. I believe it can inline everything in the same library
> that is not exported, right? (Is that your point (1) ?)

I think it can also inline stuff in the same library even if it's
exported. But say for example libfoo is using libphobos and
functions of libphobos are inlined into libfoo. Now there's a
bugfix in libphobos but libfoo doesn't see it, as the function was
inlined. You'd have to recompile libfoo as well.

The difficult part is, how do you know if two source files end up in
the same library? Say you compile foo.d which depends on foo2.d and
std/algorithm.d and you have the full source code for all three. Now
how do you know that you shouldn't inline from algorithm.d but you
can inline from foo2.d?

You can only be sure if foo.d and foo2.d are compiled at once. Or with
LTO. 

> 
> > If you inlined such code it wouldn't get updated if the shared
> > library was updated and you'd have two versions of the code
> > around...
> 
> Then some critical stuff simply must not be called via shared library 
> and better be translated to ... 0-argument templates.
> 
> Use cases: std.ascii and not only that. Checking ASCII isAlpha as a 
> _function call_ is madness.

That solution is also often used in C: Use macros for small functions
that always need to be inlined. It's not exactly pretty but I don't
know a better solution.