W dniu poniedziałek, 20 listopada 2017 22:53:30 UTC+1 użytkownik Sebastian Biały
napisał:
> On 11/20/2017 1:42 PM, Maciej Sobczak wrote:
> >> 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.
>
> Sprawdź to lepiej ile zajmuje jądro *plus* wszystkie moduły we
> wszystkich konfiguracjach i jaki jest poziom trudności tego w porownaniu
> z przeciętną aplikacją "normalną". Może się okazać że wydajnośc linikodu
> na dobę jest znaczaco mniejsza niż w jakiejkolwiek innej aplikacji z
> powodu specyfiki produktu.
>
> > 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ć.
>
> Innymi słowy przechodzisz do atakowania faktów aż wystraszone pochowają
> się po norach. No więc to działa tylko w polityce. W technice można
> najzwyczajniej sprawdzić rozmiar naciskając szary + w total commanderze.
>
> > 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ąć.
>
> Wiadomo. Zawsze możesz sie zatrudnić w jednej z firm (a niektóre mają
> oddziały w PL) i nawrzeszczeć na swojego kierownika że imbecyl i zaraz
> mu pokażesz jak się pisze prawdziwy soft redukuja dllki do 5% rozmiaru
> pierwotnego. To co, jesteś gotowy do pokazania światu jak sie pisze?
> Zwróć jednak uwagę łaskawym okiem ze docelowy rozmiar dll nie jest
> krytycznym parametrem decydującym o sprzedaży lub nie softu na rynku.
>
> > Dla przykładu, ostatnia gigantyczna DLLka jaką widziałem
>
> Nikt tu nie pisze o gigantycznych dllkach. Piszę natomiast o
> gigantycznej liczbie dllek. Na codzien pracuje z projektem gdzie jest
> ich koło setki i mają sumeryczny rozmiar 0.5GB co jest raczej
> mikroskopijna wielkością w tej branży. Tak, to *jedna* aplikacja.
>
> > , miała w sobie wpałowany jako resource jakiś odjechany jeden plik z danymi.
>
> 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.
>
> > Może to jest jakiś trop?
>
> Nie. To tylko brednie.
>
> > 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 zatrudnij się w jednej z większych firm programistycznych w okolicy
> które nie trzepią gównianego outsorcingu i sam sprawdzisz w praktyce jak
> doświadczenia hobbystyczne z hello world mają się nijak do praktyki.
>
> > 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, skoro nie wie że można miec jedną zmienną statyczna na całą
> aplikację. Wiesz, niektóre porady są niezwykle cenne tylko w teorii.
> Brakuje ci pokory przed ogromem zagadnień jakie znajdziesz w tego typu
> aplikacjach. I wiele z nich nie ma związku z programowaniem ale ma na
> programowanie wpływ.
>
> >> 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ć.
:-)
>
> I nie zerkasz dzięki czemu zyjesz w bąblu nieświadomości że moga istnieć
> aplikacje gdzie kod wynikowy ma gigabajty. Sprawdź a potem zrewiduj
> swoje hobbystyczne poglądy na programowanie. Możesz zacząć od
> sprawdzenia ile dllek jest w windowsie 10 po instalacji i jaki mają
> rozmiar a nastepnie pomyśleć o liczbie stanów kwantowych wszechświata
> potrzebnych do ich wygenerowania. Albo wrócić na ziemię.
>
> >> 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
>
> Brednia. Nic nie zakaldasz bo nie ma takiego założenia. dll mają
> pozwolic na współdzelenie kodu na jednej maszynie, jak coś sobie
> rozpraszasz to masz do czynienia z *wyjątkiem* a nie regułą i jest to
> poza ta dyskusją o przydatności dllek.
>
> >> 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.
>
> Zakładasz że oprogramowanie pisza gimazjaliści na zlecenie? No wiec to
> też prawda, ale nie dotyczy raczej aplikacji po kilka GB kodu.
>
> > 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ć.
>
> Nie rozpraszaj tak od razu wszystkiego bo ktoś może zapytać jak
> kosztowna jest synchronizacja i IPC. W realnym świecie ludzie zadają
> takie pytania.
>
> > Niemniej, przykład binarki na kilka GB wzbudza u mniej więcej wątpliwości, niż
mnie przekonuje.
>
> Wiadomo, głupie fakty znowu nie pasują do poważnych bredni.
>
> > Obliczenia powyżej.
>
> To nie sa obliczenia. To brednie. Istnieją aplikacje gdzie kod wynikowy
> liczony jest w gigabajtach na *jedną* aplikację i machanie rękami nic
> tutaj nie zmieni, to są fakty. Sugerowanie ze go źle robią jest żałosne.
> Tak, nie robią go optymalnie, ale chwilowo nie znamy lepszych metod niż
> ten kod jednak generować ponieważ to jest zawsze balans pomiedzy
> jakoscia, szybkością, ceną itp nieistotnymi dla hobbysty parametrami...

podstawowe pytanie coz to są za aplikacje dokladnie? wszystkie te dllki ladują do
jednej przestrzeni windowsowego procesu na raz?
moze to nie zwykle aplikacje (pojedyncze programy) a jakies cale zlozone systemy
programow? (pytanie zasadne bo jesli to wszystko to jest czysty kod musi to byc cos o
wiele bardziej zlozonego niz taki windows dla przykladu (ktorego kod jak mysle
wczytany do ramu to raczej jest w granicach kilkudziesieciu MB (nie licze dotnetowego
crapu i bardziej peryferyjnych dllek i programow, z tym by bylo oczywiscie sporo
wiecej ale to nie jest wszystko na raz ladowane do pamieci)) )

kolega trzeb zaznaczyc wydziela z siebie wiele konfronatacyjnych wyrzyknikow a malo
konkretnych informacji co nie robi za dobrego
wrazenia