On Sunday, November 17, 2013 13:06:11 Chris Nicholson-Sauls wrote:
> Something I'm wondering: if one were to split the implementation
> along these lines:
>
>
> void error (string file = __FILE__, size_t line = __LINE__,
> Args...) (string msg, Args args) {
> errorImpl(file, line, msg, args);
> }
>
> void errorImpl (Args...) (string file, size_t line, string msg,
> Args args) {...}
>
>
> What are the chances of the middle-man function being inlined,
> thus cutting down on template bloat in the final product? I
> should hope it would be practically guaranteed.
Without using -inline, the odds are zero. With the -inline... maybe. To be
honest, dmd's inliner is horrible. e.g. it completely fails to inline any of
std.ascii right now even though almost everything in there is a one line
function. As I understand it, the fact that error and errorImpl are templates
make it much more likely that they'll be inlined, but you'd have to compile
them with -inline and look at the generated assembly code to find out for sure.
We really, really need to improve the inliner.
But regardless, inlining has no effect on "template bloat." The fact that the
function was inline does not get rid of the fact that it was instantiated, and
it's possible that it would be inlined in some circumstances and not in
others, making it so that the function definition would have to stick around.
Also, I don't think that dmd does a very good job of stripping out template
instantiations that aren't needed anymore (e.g. the ones used in template
constraints like isForwardRange or isSomeString), so it _definitely_ isn't
going to be smart enough to remove an instantiated template that's been
inlined and then not used somewhere where it wasn't inlined.
- Jonathan M Davis
