> Nie jesteś w stanie przeprowadzić doświadczenia, jest zbyt kosztowne.
> Możesz liczyć jednak że exe będzie miał powiedzmy 2GB rozmiaru jesli
> suma dllek jest rzedu 2.5GB.

To ciekawa wartość. Bo np. o Linuksie (o jądrze, co niektórzy używają jako jakiś
znany punkt odniesienia w dyskusji o rozmiarach) mówi się, że ma ileś tam milionów
linii kodu i to jest warte ileś tam tysięcy lat pracy a po skompilowaniu jest tego
jakieś tam... megabajty. A tu mamy w dyskusji gigabajty. Z tego by wynikało, że tego
programu jest powiedzmy dwa rzędy wielkości więcej, niż Linuksa, czyli na oko miliard
linii kodu i milion lat pracy. Co z kolei każe poddać pod wątpliwość, czy w ogóle
taki program dało się na tej planecie napisać. A jeśli uznamy, że się nie dało, to
wniosek jest taki, że binarka jest rozdmuchana i pewnie da się z niej coś zdjąć.

Dla przykładu, ostatnia gigantyczna DLLka jaką widziałem, miała w sobie wpałowany
jako resource jakiś odjechany jeden plik z danymi. Po pouczeniu programistów, że tak
się nie robi (sprawa się rypła, bo się Visual na tym wywalał) i wyrzuceniu pliku
do... osobnego pliku (wczytywanego przez program w razie potrzeby!), DLLka schudła do
kilobajtów i chyba w ogóle przestała być potrzebna.
Może to jest jakiś trop?

W każdym razie, ja nie umiałbym naklepać tyle kodu (nawet z kolegami), żeby mi się
zrobiło z tego parę GB, więc jeżeli ktoś ma taką binarkę, to albo goście od Linuksa
mogą się od niego uczyć, albo on może się uczyć od gości od Linuksa, bo się te liczby
w jedną albo drugą stronę nie zgadzają.
No w każdym razie jakiś przepływ porad i doświadczeń byłby korzystny.

> b) ilośc zmiennych statycznych które musisz zainicjować od razu jest
> większa niż gdy aplikacja ladowana jest po kawałku, co spowolni proces
> startu.

A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?
Nie mylić statycznego linkowania ze statycznym zarządzaniem obiektami. Mój statycznie
zlinkowany program startuje szybciej, niż się ładuje z dysku, zmienne statyczne nie
mają związku ze statycznym linkowaniem.

> Jeśli chcesz zobaczyć *naprawdę* duże aplikacje to zerknij na rynek EDA.

Tak, wiem. Chyba w każdej dyskusji, jaką tu mieliśmy, miałem sobie tam zerkać. :-)

> Dla ilustracji: zakładając że masz 100MB kodu w dll i musisz szerować to
> między dwa exe (bo taką masz architekturę).

Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona (i
zwykle tak jest, prędzej lub później). To znaczy, że dwa procesy raczej nie są na
jednym komputerze (albo nie mogę założyć, że będą) i wtedy dzielenie kodu za pomocą
DLL nie działa - tzn. nie ma żadnej wartości w kontekście oszczędzania pamięci.
Natomiast N komunikujących się statycznie zlinkowanych programów (być może na
niezależnych komputerach) działa wybornie, dając mi pełną swobodę wdrożeniową (której
DLL nie dają).

> Dla ilustracji2: wyobraź sobie że masz aplikację edytora która tylko
> wtedy kiedy trzeba laduje parser gramatyki Perla.

To jest przypadek, który opisałem na samym początku dyskusji (o pluginach, które są
częścią kultury używania programu). Nie mam problemu z tym, że takie coś jest w DLL.
Natomiast nadal mam problem z tym, że takie coś może być użyte tylko raz w czasie
działania programu - i pytanie, czy program zadba o to, żeby takiego niepotrzebnego
DLLa odpiąć. Jak zadba, to fajnie.
Nadal jest jeszcze opcja rozproszona, czyli parser w osobnym procesie (wtedy DLL i
tak nie jest potrzebny). Może to mieć sens, może nie mieć.

Niemniej, przykład binarki na kilka GB wzbudza u mniej więcej wątpliwości, niż mnie
przekonuje. Obliczenia powyżej.

--
Maciej Sobczak * http://www.inspirel.com