Sun, 10 Jan 2010 16:45:56 -0500, bearophile wrote: > Chris: >> Execution speed perhaps, since the time elapsed is proportional to the >> number of processor instruction executed. This explains why some people >> (for certain time critical apps) do not even take the step from C to >> C++, and chose to stay 20 year behind "modern" languages. > > In real programs what takes time are (beside I/O and cache issues that > are another form of I/O) often small amounts of code, usually loops > inside loops. Removing a single instruction inside them can reduce the > running time by K%, while removing a megabyte of code elsewhere may just > reduce a little the loading time, etc. > > >> D presented itself being a high level language suitable for system >> programming, so executable sizes must be taken into consideration, >> imho. > > I don't think we'll see miracles soon, but D2 is currently in alpha > state still. Once it's in beta some care will be probably given to > optimizations too, and among them there is the executable size too. Even > if most people don't need such optimization, it's clearly > psychologically required by C/C++ programmers. Eventually it's even > possible to add a compilation flag to D compilers to not use the GC, > avoiding that overhead on C-like programs (such flag must also turn some > operations into compilation errors, like array join, etc, to avoid > leaks). Currently Link Time Optimization of LLVM (that can be used by > LDC) removes some unused code from D1 programs.
At least you're admitting that a problem really exists. Some D users even see the problems as important and desired features - "Your exe consumes 500 MB of space? But that's a good thing. Now you can be certain that you have a valid reason for finally purchasing that 10 TB raid-5 array."
