> Sprawdź to lepiej ile zajmuje jądro *plus* wszystkie moduły

Nadal megabajty. Podobno kilkadziesiąt.

> i jaki jest poziom trudności tego w porownaniu
> z przeciętną aplikacją "normalną".

A to poziom trudności wpływa na stosunek rozmiaru binarki względem liczby linii kodu?
Ja piszę o tym, że jeżeli weźmiemy Linuksa jako pewny znany punkt odniesienia, to
przykład wielogigabajtowych DLLek tak bardzo od tego punktu odniesienia odbiega, że
aż się prosi o wyjaśnienie. I tego wyjaśnienia nadal nie widać.

> Innymi słowy przechodzisz do atakowania faktów

Ja podałem fakty z Linuksa.

> W technice można
> najzwyczajniej sprawdzić rozmiar naciskając szary + w total commanderze.

Nie napisałem nigdzie, że plik nie może mieć takiego rozmiaru, tylko że (w porównaniu
do znanego punktu odniesienia) ten rozmiar ma wątpliwe uzasadnienie.

> Zawsze możesz sie zatrudnić w jednej z firm (a niektóre mają
> oddziały w PL) i nawrzeszczeć na swojego kierownika że imbecyl

Zauważyłem, że za każdym razem gdy o czymś dyskutujemy pojawiają się dwa stałe
zjawiska:
1. mam sobie zerknąć na EDA
2. w Twoich postach pojawiają się wyzwiska

> Zwróć jednak uwagę łaskawym okiem ze docelowy rozmiar dll nie jest
> krytycznym parametrem decydującym o sprzedaży lub nie softu na rynku.

I w ten sposób sam podrzuciłeś argument do dyskusji wskazując, że nie ma motywacji,
żeby te DLLki były mniejsze.
Wstępne podsumowanie:
- ja stawiam zarys tezy, że taki rozmiar może nie być optymalny
- Ty stwierdzasz, że nie ma motywacji biznesowej, żeby był optymalny

Czyli nie ma między nami różnicy zdań, wbrew Twojemu wyobrażeniu, że ktoś kogoś
atakuje, itd.

> Nikt tu nie pisze o gigantycznych dllkach. Piszę natomiast o
> gigantycznej liczbie dllek.

Dobrze, popracujmy nad tym argumentem.
Napisałem pustą funkcję w C i bez żadnych optymalizacji zrobiłem z niej:
- plik obiektowy: 687 bajtów
- archiwum do linkowania statycznego: 840 bajtów
- dynamiczną bibliotekę dzieloną: 56731 bajtów

W przypadku linkowania z archiwum wyciągany jest sam tekst funkcji, więc tu narzutu
nie ma. Natomiast biblioteka dzielona jest 80 (słownie: osiemdziesiąt) razy większa,
niż plik obiektowy. Oczywiście ten narzut jest sztucznie zawyżony przez sam fakt, że
funkcja jest pusta, ale...

> Na codzien pracuje z projektem gdzie jest
> ich koło setki i mają sumeryczny rozmiar 0.5GB

... ale powinno być zrozumiałe, że skoro DLL ma pewne wewnętrzne narzuty, to suma
rozmiaru dużej liczby DLLek nie przekonuje mnie, że w sumie tyle tych bajtów musi
być.

> Ja zaś, rozumiesz, mialem taki przypadek że kiedys jak siadałem to pękło
> ramię w fotelu na kółkach i przewróciłem kubek z herbata na klawiature.
> Z tego wniosek że LG wszystkie klawiatury dziadowskie robi.

Ja takiego wniosku bym nie wyciągnął, ale cieszę się, że się z nami tym podzieliłeś.

> > Może to jest jakiś trop?
>
> Nie. To tylko brednie.

Więc powinno być bardzo łatwo to wykazać. A tymczasem od początku stwierdziłeś, że
odpowiedniego doświadczenia nie możesz przeprowadzić.

> Więc zatrudnij się w jednej z większych firm programistycznych w okolicy

A mógłbyś coś polecić?

> sam sprawdzisz w praktyce jak
> doświadczenia hobbystyczne z hello world mają się nijak do praktyki.

Praktyka jest taka, że nie ma motywacji, żeby było optymalnie. Sam tak napisałeś.

> > A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?
>
> Znowu masz opcje: idziesz do kierownika projektu i nazywasz go
> imbecylem,

Znowu wyzwiska. A może faktycznie można mieć mniej zmiennych statycznych?
Albo nawet w ogóle ich nie mieć?

> Brakuje ci pokory

Bo podałem liczby, z którymi nie wiesz, co zrobić?

> Możesz zacząć od
> sprawdzenia ile dllek jest w windowsie 10 po instalacji

Faktycznie można od tego zacząć, bo w pierwszym poście w tej dyskusji napisałem, że
base-system jest wyjątkiem, gdzie kod dzielony jest uzasadniony. Ale dyskutujemy o
aplikacjach.

> > Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona
>
> Brednia. Nic nie zakaldasz bo nie ma takiego założenia.

Tak zakładam i do tej pory się to sprawdzało.
Co ciekawe, zrobiłem zgodnie z Twoim zaleceniem i zerknałem do branży EDA, żeby
skonfrontować swoje hobbystyczne wyobrażenie z prawdziwym światem:

https://www.google.com/patents/US20070073809

i popatrz jaka niespodzianka - tam też się sprawdziło.

(Właśnie dlatego nie traktuję branży EDA jako wyjątkowego źródła olśnień albo
przykładów. Branża jak inne.)

> Zakładasz że oprogramowanie pisza gimazjaliści na zlecenie?

O, w poprzedniej dyskusji też coś wspominałeś o gimnazjalistach.

> No wiec to
> też prawda, ale nie dotyczy raczej aplikacji po kilka GB kodu.

Ale jeszcze nie wykazałeś, że te GB są uzasadnione. Wręcz przeciwnie - sam wskazałeś,
że nie ma motywacji, żeby było tego mniej, czym tylko utwierdziłeś mnie w moich
wątpliwościach w tym temacie.

> Wiadomo, głupie fakty znowu nie pasują do poważnych bredni.
>
> > Obliczenia powyżej.
>
> To nie sa obliczenia. To brednie.

Ciekawe, ile osób przekonałeś.

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