Lib change leads to larger executables

[Walter Bright]

kris wrote:
> Walter Bright wrote:
>> Some strategies:
>>
>> 1) minimize importing of modules that are never used
>>
>> 2) for modules with a lot of code in them, import them as a .di file 
>> rather than a .d
>>
>> 3) create a separate module that defines the relevant typeinfo's, and 
>> put that first in the library
> 
> 
> 1) Tango takes this very seriously ... more so than Phobos, for example.

Sure, but in this particular case, it seems that "core" is being 
imported without referencing code in it. The only reason the compiler 
doesn't generate the char[][] TypeInfo is because an import defines it. 
The compiler does work on the assumption that if a module is imported, 
then it will also be linked in.

> 2) That is something that could be used in certain scenario's, but is 
> not a general or practical solution for widespread use of D.

The compiler can automatically generate .di files. You're probably going 
to want to do that anyway as part of polishing the library - it speeds 
compilation times, aids proper encapsulation, etc. That's why the gc 
does it, and I've been meaning to do it for other bulky libraries like 
std.regexp.

I wish to point out that the current scheme does *work*, it generates 
working executables. In the age of demand paged executable loading 
(which both Linux and Windows do), unused code in the executable never 
even gets loaded into memory. The downside to size is really in shipping 
code over a network (also in embedded systems).

So I disagree with your characterization of it as impractical.

For professional libraries, it is not unreasonable to expect some extra 
effort in tuning the libraries to minimize dependency. This is a normal 
process, it's been going on at least for the 25 years I've been doing 
it. Standard C runtime libraries, for example, have been *extensively* 
tweaked and tuned in this manner, and that's just boring old C. They are 
not just big lumps of code.

> 3) Hack around an undocumented and poorly understood problem in 
> developer-land. Great.

I think you understand the problem now, and the solution. Every 
developer of professional libraries should understand this problem, it 
crops up with most every language. If a developer doesn't understand it, 
one winds up with something like Java where even the simplest hello 
world winds up pulling in the entire Java runtime library, because 
dependencies were not engineered properly.

> you might as well add:
> 
> 4) have the user instantiate a pointless and magic char[][] in their own 
> program, so that they can link with the Tango library?

I wouldn't add it, as I would expect the library developer to take care 
of such things by adding them to the Tango library as part of the 
routine process of optimizing executable size by minimizing dependencies.

> None of this is not gonna fly in practice, and you surely know that?

For features like runtime time identification, etc., that are generated 
by the compiler (instead of explicitly by the programmer), then the 
dependencies they generate are a fact of life.

Optimizing the size of a generated program is a routine programming 
task. It isn't something new with D. I've been doing this for 25 years.

> I get a subtle impression that you're being defensive about the problem 
> rather than actively thinking about a practical solution? We're trying 
> to help D get some traction here, yet it seems you're not particularly 
> interested in removing some roadblocks? Or are you scheming a resolution 
> in private?

If you have any ideas that don't involve reinventing obj file formats or 
that don't preclude using standard linkers, please let me know.