How to stop DMD from exploding the executable file size?

[max haughton]

On Saturday, 3 September 2022 at 00:49:36 UTC, ryuukk_ wrote:
> On Friday, 2 September 2022 at 17:53:51 UTC, max haughton wrote:
>> On Tuesday, 30 August 2022 at 22:51:46 UTC, ryuukk_ wrote:
>>> Having this simple code makes the executable gigantic!
>>>
>>> ```D
>>> struct Big
>>> {
>>>     int[1024 * 1024] big = 0;
>>> }
>>>
>>> Big big;
>>> ```
>>>
>>> Only with DMD, LDC produces a tiny executable
>>>
>>> Is there a flag available to fix this behavior? it's not 
>>> sustainable
>>
>> You really shouldn't have structs this big unless absolutely 
>> necessary.
>>
>> The thing being elided is the initializer and pointer bitmap 
>> for the runtime to use.
>
> My use case should not makes us blind about the issue DMD is 
> having
>
> I tested with both C and Zig, and they both produce small 
> executable
>
> If DMD can do it on linux, there is no reason it can't do it on 
> windows, if LDC can do it for both
>
> I want to promote D, i can't promote D if i tell people "yeah 
> but X, Y, Z, then you should go with X, when Z, and when stars 
> are aligned, maybe"
>
> It just feels bad; and the list of things that feels bad starts 
> to stack up to a point it becomes sad

If this is what stops them from using D they're using it as a toy 
- it's a completely nonsensical pattern 99% of the time. Huge 
structs usually imply a lack of understanding, for example you 
could easily blow up the stack.

I will at very least try and fix this in dmd, it's just the 
object emission code being overly conservative (ldc will emit the 
initializer if you do something that actually needs it), but if 
this is what stops them using D I would be very skeptical. C 
doesn't even have struct default-initializers.

In reality, the stars have to align the other way - we have lots 
of people writing D code every day, some of which might not be 
entirely sure what an object file even is, 99% of the time this 
kind of stuff just doesn't matter.

In line with the above statement, the actual answer here is to 
try and compress the big initializers rather than faff around 
with whether they are used or not - should the compiler focus on 
dead code elimination rather than optimizing the stuff that 
actually runs?

Most of these initializers will be zero, god forbid someone does 
statically allocate their tensor in a structure potentially we 
can give them a speed/size tradeoff.

Everyone making a living out of D's workflow that I'm aware of is 
prototype with dmd, ship with ldc or gdc. This should be 
enshrined in the toolchain, it is not currently but maybe it will 
be sooner rather than later.

I do like small binaries but I can count on 1 hand the number of 
times it's seemed important and on zero hands the number of time 
it's actually mattered in practice.

If it, in your estimation, does make it a difference it may be of 
note that PGO can make the inlining much more intelligent and 
thus save you potentially even double digit percentages of the 
non-PGO build's size.