April 20, 2016Re: Policy for exposing range structs
Posted in reply to Steven Schveighoffer
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.
Copyright © 1999-2018 by the D Language Foundation