On Tuesday, 19 April 2016 at 17:59:48 UTC, Steven Schveighoffer wrote:
> On 4/19/16 10:44 AM, Johan Engelen wrote:
>
>> The feature is experimental, and has been tested on Weka.io's codebase.
>> Compilation with -hashthres=1000 results in a binary that is half the
>> size of the original (201MB vs. 461MB). I did not observe a significant
>> difference in total build times.
>
> I'd be surprised link times did not improve. With my trivial test cases, the linker started getting hung up with very long symbols. The compilation itself was quick though.

`nm` on my Mac cannot handle the long symbol names, and I have to use llvm-nm :)

> Certainly, cutting exe sizes (this is significantly more than half, BTW) is a good thing in itself.
>
> Another thing, however, is memory usage of the compiler. My understanding is that having large symbol names requires more memory. How does that fare?

I don't know. Generating the (unhashed) mangled symbol names seems fast. LDC is using so much memory (>6 GB) that I think a few extra megabytes for symbol names is not noticeable (the symbol name is cached for functions; adding caching for other symbol mangled names did not change compile times but I didn't look at memory). What worries me is that std.traits is doing all that string processing for simple things like getting the storage class of a function parameter. When it starts to do CTFE on a string that is 1 MB, that's not good I think.