[Issue 14571] [REG2.064] Large static arrays seem to lock up DMD

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14571

--- Comment #18 from Manu <turkeyman at gmail.com> ---
(In reply to Walter Bright from comment #6)
> I'll fix this, but you should know that this necessarily creates large
> sections in the executable file of repeated data. For such large arrays, it
> is better to allocate and initialize them on program startup.

I reported it because it was a bug, and I agree it's not excellent practise.
That said though, Vladimir has already presented my thoughts; it's perfectly
valid code, people do it, code like this exists.
In my case, I am porting C++ code, and it's quite a lot of code... it is
difficult to refactor and port at the same time.


Regarding .init, this is something I never really thought about too much, but
I'm now really concerned. I have been concerned by classinfo's in the past, but
somehow init slipped under my radar.
I think a few things need to be considered and/or possible.

1. How do I disable the existence of 'init' for a type? It's conceivable that I
want to produce an uninitialised (and uninitialisable) type, like these ones I
have here.

2. Any type with a static array naturally has an unreasonably large .init
value; what optimisations are possible with relation to init? Can they be
alocated+synthesised at init (*cough*) time, rather than built into the exe?
An array is a series of repeated elements, so storing that full array in the
binary is not only wasteful, but can only lead to disaster when people put a
static array as a member of a type, and the length is large, or perhaps is fed
from a 3rd party who doesn't have this specific consideration in mind (nor
should they).

3. Can D effectively link-strip .init when it is un-referenced? How can we make
this possible if there is something preventing it?

I'd love to spend some time working towards D binaries being the same
predictable size as C/C++ binaries. For some reason, despite my efforts, I
always seem to end up with D binaries that are easily 10 times the size of
their counterpart C binary.
Infact, I constantly find myself in the surprising situation where I create a D
interface for a C lib, which simply declares extern(C)'s along with minimal D
code for adaptation, no actual functional D code in sight, and the .lib it
produces is significantly larger than the entire C lib that it represents.
I have never taken the time to explore the problem, I suspect it's just
classinfo's and init values... are there other known bloat inducing problems?


> The way globals work on modern CPUs is you are not saving any execution time
> by using static data. Large static arrays is an artifact of FORTRAN.

This isn't about execution time, it's about perfectly valid code that looks
completely benign causing an unexpected explosion to your binary.
Not all programmers are aware or conscious of this sort of thing. It shouldn't
be so simple for an unexpecting (junior?) programmer to make a mess like this,
and likely not understand what they've done, or that they've even done it at
all.

--