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.
