DMD producing huge binaries

[ZombineDev via Digitalmars-d]

On Friday, 20 May 2016 at 13:16:32 UTC, Johan Engelen wrote:
> On Friday, 20 May 2016 at 12:57:40 UTC, ZombineDev wrote:
>>
>> As I said earlier, it would be best if can prevent the 
>> generation of long symbols in the first place, because that 
>> would improve the compilation times significantly.
>
> From what I've observed, generating the long symbol name itself 
> is fast. If we avoid the deep type hierarchy, then I think 
> indeed you can expect compile time improvement.
>
>> Walter's PR slows down the compilation with 25-40% according 
>> to my tests. I expect that compilation would be faster if the 
>> whole process is skipped altogether.
>
> MD5 hashing slowed down builds by a few percent for Weka (note: 
> LDC machinecodegen is slower than DMD's, so 
> percentage-wise...), which can then be compensated for using 
> PGO ;-)  /+  <-- shameless PGO plug  +/

IIUC, your scheme works like this:
1. DMDFE creates a mangled symbol name
2. Create a MD-5 hash of thr symbol use the hash instead of the 
full name.

If minimal change in Georgi's almost trivial program w.r.t LoC 
(compared to e.g. Weka's huge codebase) increases compilation 
time from 1.5sec to 27sec, I can't imagine how slower it would 
take for a larger project.

We should cure root cause. Genetating uselessly large symbols 
(even if hashed after that) is part of that problem, so I think 
it should never done if they start growing than e.g. 500 bytes.

The solution that Steven showed is exactly what the compiler 
should do. Another reason why the compiler should do it is 
because often voldemort types capture outer context (local 
variables, alias paramters, delegates, etc.), which makes it very 
hard for the user to manually extract the voldemort type out of 
the function.