Compilation times and idiomatic D code

Olivier FAURE via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 18 01:36:51 PDT 2017


On Monday, 17 July 2017 at 18:42:36 UTC, H. S. Teoh wrote:
>> Besides the symbol problem though, does the template 
>> instantiation explosion problem imply as many duplicated 
>> function bodies corresponding to the new type symbols?
>
> That's a different, though somewhat related, issue.  I have 
> some ideas on that front, but for now, Rainers' PR addresses 
> only the problem of symbol length.  So the next task after his 
> fix is merged is to tackle the larger problem of how to improve 
> the implementation of templates.
>
> [...]
>
> Often, this results from templates that contain helper code 
> that's independent of the template parameters, or dependent 
> only on a subset of template parameters. For example:

Yeah, I think this is the second best optimization for symbol 
names after using references for duplicates symbol subnames.

One thing you didn't mention is that this also creates a lot of 
useless duplicate for Voldemort types in template functions that 
don't depend on (all of) the functions parameters. For instance, 
looking at the code from the OP's issue:

     auto s(T)(T t)
     {
         struct Result
         {
             void foo(){ throw new Exception("2");}
         }
         return Result();
     }

     void main(string[] args)
     {
         auto x = 1.s.s.s.s.s;
         x.foo;
     }

foo mangles to a super long symbol, even though the actual symbol 
should be something like

     moduleName.s!(__any_type)(__any_type).Result.foo

Actually, it's a little more complicated than that, because s 
might have overloads the compiler is not aware of, which means it 
doesn't trivially know that T doesn't matter to result.

Still, pretty sure there are optimizations to be had there.

One possibility would be to allow the coder to give unique 
subnames to functions. For instance

     int add.withInts(int n1, int n2)
     float add.withFloats(float n1, float n2)

This would allow the compiler to assume that a function's 
mangling is unique, without having to worry about overloads and 
other templates, and therefore skip the unnecessary parameters 
the function's Voldemort type.


More information about the Digitalmars-d mailing list