https://issues.dlang.org/show_bug.cgi?id=14571
--- Comment #19 from Vladimir Panteleev <thecybersha...@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. --
