DMD producing huge binaries

[poliklosio via Digitalmars-d]

On Thursday, 19 May 2016 at 13:45:18 UTC, Andrei Alexandrescu 
wrote:
> On 05/19/2016 08:38 AM, Steven Schveighoffer wrote:
>> Yep. chain uses voldemort type, map does not.
>
> We definitely need to fix Voldemort types. Walter and I bounced 
> a few ideas during DConf.
>
> 1. Do the cleartext/compress/hash troika everywhere (currently 
> we do it on Windows). That should help in several places.
>
> 2. For Voldemort types, simply generate a GUID-style random 
> string of e.g. 64 bytes. Currently the name of the type is 
> composed out of its full scope, with some 
> exponentially-increasing repetition of substrings. That would 
> compress well, but it's just a lot of work to produce and then 
> compress the name. A random string is cheap to produce and 
> adequate for Voldemort types (you don't care for their name 
> anyway... Voldemort... get it?).
>
> I very much advocate slapping a 64-long random string for all 
> Voldermort returns and calling it a day. I bet Liran's code 
> will get a lot quicker to build and smaller to boot.
>
>
> Andrei

I have an Idea of reproducible, less-than-exponential time 
mangling, although I don't know how actionable.

Leave mangling as is, but pretend that you are mangling something 
different, for example when the input is
foo!(boo!(bar!(baz!(int))), bar!(baz!(int)), baz!(int))
pretend that you are mangling
foo!(boo!(bar!(baz!(int))), #1, #2)
Where #1 and #2 are special symbols that refer to stuff that was 
**already in the name**, particularly:
#1: bar!(baz!(int))
#2: baz!(int)

Now, this is an reduction of the exponential computation time 
only if you can detect repetitions before you go inside them, for 
example, in case of #1, detect the existence of bar!(baz!(int)) 
without looking inside it and seeing baz!(int). Do you think it 
could be done?

You would also need a deterministic way to assign those symbols 
#1, #2, #3... to the stuff in the name.

Compression can also be done at the end if necessary to reduce 
the polynomial growth.