<div dir="ltr">On 21 September 2013 09:02, H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx" target="_blank">hsteoh@quickfur.ath.cx</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Sep 20, 2013 at 05:04:23PM -0400, Nick Sabalausky wrote:<br>
> On Fri, 20 Sep 2013 21:45:48 +0200<br>
> "Temtaime" <<a href="mailto:temtaime@gmail.com">temtaime@gmail.com</a>> wrote:<br>
> ><br>
> > Software MUST running almost ANYWHERE and consumes minimal<br>
> > resources.<br>
> ><br>
> > For example i hate 3dsmax developers when on my game's map it uses<br>
> > several GB of ram amd freezes sometimes, when Blender uses only 500<br>
> > MB and runs fast. The only reason for me for use 3dsmax is more<br>
> > friendly contoling. But this is another story...<br>
> ><br>
> > Some users which doesn't have ""modern"" PC will hate your app too i<br>
> > think.  One should optimize ALL things which he can to optimize.<br>
> ><br>
><br>
> I agree with what you're saying here, but the problem is we're looking<br>
> at a difference of only a few hundred k.<br>
><br>
> Heck, my primary PC was a 32-bit single-core right up until last year<br>
> (and I still use it as a secondary system), and I didn't care one bit<br>
> if a hello world was 1k or 1MB.<br>
<br>
</div>I agree with the OP that dmd should improve dead-code culling, though.<br>
Recently Walter has started doing lazy template instantiation for<br>
imports, which begins to trim off some of the fat. But there's plenty of<br>
room for more improvements.<br>
<br>
For example, after seeing Walter's recent pulls, I got inspired to write<br>
a simple utility that takes the output of objdump -d (the disassembly of<br>
an executable) and parses it to extract code symbols from the program<br>
along with references to other symbols. It then builds of graph of how<br>
symbols reference each other, and performs some trivial reachability<br>
analysis on it. It revealed some startling results... like the fact that<br>
symbols from std.complex are included in a hello world program, even<br>
though complex numbers are never used!<br>
<br>
The ratio of total number of symbols to symbols transitively reachable<br>
from _Dmain is rather large, ranging from 5 (medium-sized, complex<br>
program) to about 30 (a hello world program). Now I'm not 100% confident<br>
about the accuracy of these numbers, since some symbols may be<br>
indirectly referenced, and thus missed in the graph built from parsing<br>
the disassembly. But still, even when taken as ballpark figures, it<br>
shows that there's a *lot* of room for improvement. Certainly, some of<br>
the unreferenced symbols are druntime overhead (used by startup/exit<br>
functions, etc.), but a ratio of *5*? That's a 5x executable size bloat.<br>
Even if we discount half of that for druntime overhead and indirect<br>
references... I mean, how many indirect references can you have?  I<br>
really can't convince myself that's "merely" druntime/phobos overhead.<br>
Especially when I see symbols from std.complex in a program that doesn't<br>
even use complex numbers. std.complex shouldn't be in there in the first<br>
place, before we even talk about template bloat.<br>
<div class="im"><br>
<br>
> How many real world programs are as trivial as a hello world? A few<br>
> maybe, but not many. Certainly not enough to actually add up to<br>
> anything significant, unless maybe you happen to be running on a 286 or<br>
> such.<br>
><br>
> If we were talking about real-world D programs taking tens/hundreds of<br>
> MB more than they should, then that would be a problem. But they<br>
> don't. We're just talking about a few hundred k for an *entire* program.<br>
<br>
</div>My numbers show otherwise. :) Well, OK, I'm counting symbols rather than<br>
size, and the count may not be 100% accurate. But it does show that we<br>
could improve. By a lot.<br>
<br>
A hello world program, according to my test, has a ratio of 30 between<br>
total symbols and symbols reachable from _Dmain, whereas a medium-sized<br>
complex program shows a ratio of around 5 (the symbol analyser program<br>
itself, which is significantly simpler than the complex program I<br>
tested, also shows a ratio of 5). So we can probably discount the hello<br>
world case, since most of the apparent bloat is probably just one-off<br>
overhead from druntime, etc.. But the ratio of 5 for non-trivial<br>
programs? No matter how I try to rationalize it, I'm forced to conclude<br>
that there is a lot of room for improvement here. Surely *some*<br>
significant subset of these unreferenced symbols must be actually<br>
unreachable and can be pruned from the executable.<br>
<br>
I'll continue refining the analysis while Walter works on more lazy<br>
instantiations for imports. I'm expecting to see a lot of improvements<br>
in this area. :)<br></blockquote><div><br></div><div>This is awesome.</div><div>What would be really awesome is if you integrated this into the D auto-builder, and hack it publish the results somewhere for the latest build.</div>
<div>It would be good to know when people write code that results in a significant increase in coverage (particularly when it doesn't need to).</div><div>It would also provide very useful information for hackers who just want to get in and do some work to try and trim it a bit.</div>
</div></div></div>