Policy for exposing range structs

[Johan Engelen via Digitalmars-d]

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.