Bug 7921 – Two order of magnitude file size increase (up to 111 MiB for GtkD) mostly from zeroes

An example: GtkD is built using singe (gtk-one-obj.lib) or separate (one per source file) object files (gtk-sep-obj.lib). Than main.d that imports gtk.Main is built using those libraries. Than zeroCount utils is built and launched over resulting files: -------------------------------------------------- Zero bytes| %| Non-zero| Total bytes| File 3628311| 21.56| 13202153| 16830464|gtk-one-obj.lib 1953124| 15.98| 10272924| 12226048|gtk-sep-obj.lib 127968798| 99.00| 1298430| 129267228|main-one-obj.exe 743821| 37.51| 1239183| 1983004|main-sep-obj.exe -------------------------------------------------- These zero byte counts are similar for dmd 2.054-2.057. So one has to use very slow per-file build to produce a good (not 100 MiB) executable. No matter what *.exe is launched, its process allocates ~20 MiB of RAM (loaded Gtk dll-s). See also: "Building GtkD app on Win32 results in 111 MiB file mostly from zeroes" thread: http://www.digitalmars.com/d/archives/digitalmars/D/Building_GtkD_app_on_Win32_results_in_111_MiB_file_mostly_from_zeroes_141758.html A post in "Program size, linking matter, and static this()" thread: http://www.digitalmars.com/d/archives/digitalmars/D/Program_size_linking_matter_and_static_this_152387.html#N152875

This issue is fixed in dmd 2.058. But no information about its source is given.

Created attachment 1091 Example with gtkD

Make sure first that it is not this issue: http://dlang.org/faq.html#bss

(In reply to comment #3) > Make sure first that it is not this issue: > > http://dlang.org/faq.html#bss AFAIK there was no changes with BSS in dmd 2.058. And GtkD doesn't use __gshared arrays at all.

Have you looked at the map file? If not, try my map treemap visualization tool: http://thecybershadow.net/d/mapview/

Created attachment 1093 Example with GtkD

The example with built binaries for dmd 2.057 and dmd 2.058 (~10 MiB, uncompressed ~250 MiB): http://deoma-cmd.ru/files/other/huge-build-gtkD-full.7z One can use Vladimir Panteleev's treemap visualization tool with *.map files from the archive (as for me, it hangs Chrome).