[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 #19 from Vladimir Panteleev <thecybershadow at gmail.com> ---
(In reply to Manu from comment #18)
> 1. How do I disable the existence of 'init' for a type?

I think that if you make sure that all of the initial values are zero bytes,
the compiler won't generate a .init block. Instead, the TypeInfo will have a
null .init pointer, and the runtime will use that as a clue to simply do a
memset instead of copying over the .init data when allocating new types. You
might be able to also use this to ensure that your complex types aren't
accidentally creating .init blocks.

> 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?

Not at the moment, AFAIK.

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

Each .init would need to be in its own section to allow linker garbage
collection. DMD doesn't seem to do this at the moment, though (at least not on
Win32/Win64).

Whether to put things in individual sections is usually a trade-off between
link time and resulting executable size. It would be great if DMD at least gave
the user some control over this. gcc has e.g. -ffunction-sections and
-fdata-sections.

> 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.

I agree, bloated executables are not nice. This becomes a real problem with
proprietary/closed-source applications, since then the compiler is pulling in
code and data that is never actually used, and which should not be present in
the published executable.

> 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?

Yes.

- Static constructors pull in everything they reference.
- Object.factory requires that all classes that the compiler sees must be
instantiatable, which means pulling in their vtables, invariants, virtual
methods, and all their dependencies.
- Many things which could be emitted in separate sections are put in one
section. As a result, anything that's referenced within that section pulls in
everything else from it, and all their dependencies.
- There are probably other problems.

This is generally one of the more neglected aspects of D and the current
implementations. People working on embedded D stuff are constantly running into
the above problems as well.

--