DMD producing huge binaries

[Steven Schveighoffer via Digitalmars-d]

On 5/19/16 11:56 AM, Georgi D wrote:
> On Thursday, 19 May 2016 at 12:38:09 UTC, Steven Schveighoffer wrote:
>> On 5/17/16 6:04 PM, ZombineDev wrote:
>>> I'm guessing that is highly related to this one:
>>> https://issues.dlang.org/show_bug.cgi?id=15831
>>
>> Yep. chain uses voldemort type, map does not.
>>
>> Georgi: try copying chain implementation into your local file, but
>> instead of having a static internal struct, move it to a module-level
>> struct (you probably have to repeat the template parameters, but not
>> the constraints). See if it produces a similar slimming effect.
>>
>
> Yes,
>
> Making a local copy of chain and moving the structure outside of the
> method solved the problem and reduced the code size.

Thanks, that confirms the bug reports are for the same issue.

>
> The stripped size even reduced from the version that did not experience
> the huge increase. Stripped: 7.4Mb -> 5.5MB
>
> Should we actually change the implementation in phobos to be like this?

I'd much prefer we fix the compiler to handle voldemort types in a more 
sane way rather than try and fix the code to deal with compiler 
deficiencies. However, if this isn't something that's easily done (or 
done within a decent time frame), we may look at that solution.

> In the company I work in we are very sensitive to the code size so
> anything that can be made for this in phobos will help with adoption.
>
> I am still curious though why the code size increased so dramatically
> with such a small change. Both versions return a result from chain and
> actually the one that does not experience the increase is more complex
> (includes the one that does).

Each call to a voldemort wrapping function (one that wraps one type into 
another "voldemort" type, or internal struct) increases the symbol size 
at a rate of 3^n. Non-voldemort types do not suffer from this, because 
the symbol size increases at just n.

> In my actual code I have multiple calls to chain on top of the result of
> this and the code size does not increase dramatically.
>
> I am also concerned by the fact that ldc on mac just could not compile
> the source which produced the big binary (entering an infinite loop).

I would expect the possibility that the issue is with the linker. In my 
toy experiments, the compiler works just fine and produces an object 
file. It's the linker having issues with parsing those humungous symbols.

-Steve