[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

pl.comp.programming

okiem laika - dlaczego pliki wykonywalne sa takie duze?

Witek Mozga

5/1/2007 1:40:00 PM

Witam,

Programowaniem zajmuje sie jedynie hobbystycznie, jednak od d3u?szego
czasu nurtuje mnie pytanie: dlaczego pliki wykonywalne we wspó3czesnych
pecetach s? takie du?e? Pamietam gdy na?cie lat temu grzeba3em w
asemblerze mikrokomputera Commodore64, to ca3y system operacyjny
zajmowa3 kilka kilobajtów. Gra wraz z grafikami kilkadziesi?t, a
kilkaset kilobajtów stanowi3o zasoby wrecz niewyobra?alne. Obecnie
prosty program w C typu hello world po skompilowaniu i optymalizacji
zajmuje kilka KB. Z czego wynika taki du?y narzut kodu? Z
niedoskona3o?ci kompilatora? Bardzo prosta aplikacja to zazwyczaj
kilkaset KB (nie licz?c obrazków). Dlaczego tak du?o, je?li i tak
wiekszo?a z jej kodu to odwo3ania do systemu (GUI, IO, itp.). Mo?e mi
kto? wyt3umaczya czemu tak jest? Czy to oznacza, ?e tak naprawde
programy mog3yby bya dziesi?tki razy mniejsze (i szybsze), ale
postawiono raczej na szybko?a ich tworzenia ni? wykonywania?

Pozdrawiam

--
Witek
http://www.trimen...
91 Answers

Mariusz Kruk

5/1/2007 2:35:00 PM

0

epsilon$ while read LINE; do echo ">$LINE"; done < Witek Mozga
>Programowaniem zajmuje sie jedynie hobbystycznie, jednak od d3u?szego
>czasu nurtuje mnie pytanie: dlaczego pliki wykonywalne we wspó3czesnych
>pecetach s? takie du?e?

Google i poczytaj o formatach plików wykonywalnych (PE, ELF...)

>Pamietam gdy na?cie lat temu grzeba3em w
>asemblerze mikrokomputera Commodore64, to ca3y system operacyjny
>zajmowa3 kilka kilobajtów.

Szumnie nazwane.

>Gra wraz z grafikami kilkadziesi?t, a
>kilkaset kilobajtów stanowi3o zasoby wrecz niewyobra?alne.

Chyba, ?e akurat by3e? tym programuj?cym. ;-)

>Obecnie
>prosty program w C typu hello world po skompilowaniu i optymalizacji
>zajmuje kilka KB. Z czego wynika taki du?y narzut kodu?

A kto powiedzia3, ?e to narzut kodu?

>Z
>niedoskona3o?ci kompilatora?

Z nieumiejetno?ci obs3ugi google.

>Bardzo prosta aplikacja to zazwyczaj
>kilkaset KB (nie licz?c obrazków). Dlaczego tak du?o, je?li i tak
>wiekszo?a z jej kodu to odwo3ania do systemu (GUI, IO, itp.). Mo?e mi
>kto? wyt3umaczya czemu tak jest? Czy to oznacza, ?e tak naprawde
>programy mog3yby bya dziesi?tki razy mniejsze (i szybsze), ale
>postawiono raczej na szybko?a ich tworzenia ni? wykonywania?

Nie.

--
\.\.\.\.\.\.\.\.\.\.\.\.\.\ I am DirtyHarry of Borg. Go ahead and resist
..\.Kruk@epsilon.eu.org.\.\. us, punk. Make our day.
\.http://epsil...\.\
..\.\.\.\.\.\.\.\.\.\.\.\.\.

Rafal

5/1/2007 3:36:00 PM

0

Witek Mozga wrote:

> Witam,
>
> Programowaniem zajmuje sie jedynie hobbystycznie, jednak od d3u?szego
> czasu nurtuje mnie pytanie: dlaczego pliki wykonywalne we wspó3czesnych
> pecetach s? takie du?e? Pamietam gdy na?cie lat temu grzeba3em w
> asemblerze mikrokomputera Commodore64, to ca3y system operacyjny
> zajmowa3 kilka kilobajtów. Gra wraz z grafikami kilkadziesi?t, a
> kilkaset kilobajtów stanowi3o zasoby wrecz niewyobra?alne. Obecnie
> prosty program w C typu hello world po skompilowaniu i optymalizacji
> zajmuje kilka KB. Z czego wynika taki du?y narzut kodu? Z
> niedoskona3o?ci kompilatora? Bardzo prosta aplikacja to zazwyczaj
> kilkaset KB (nie licz?c obrazków). Dlaczego tak du?o, je?li i tak
> wiekszo?a z jej kodu to odwo3ania do systemu (GUI, IO, itp.). Mo?e mi
> kto? wyt3umaczya czemu tak jest? Czy to oznacza, ?e tak naprawde
> programy mog3yby bya dziesi?tki razy mniejsze (i szybsze), ale
> postawiono raczej na szybko?a ich tworzenia ni? wykonywania?

M. Kruk jak zwykle bawi sie w zagadki nie umiej?c odpowiedziea na proste
pytanie... :P

Wielko?a pliku wykonywalnego wynika z narzutu bibliotek do3?czanych do
niego, umo?liwiajace wykonanie za3o?onych w nim dzia3an. Je?li np w Pascalu
chcesz napisaa hello world i do3?czysz do programu biblioteke CRT a z niej
u?yjesz jedynie procedury gotoxy, to niestety do pliku wynikowego trafi nie
tylko samo gotoxy, ale równie? ca3y skompilowany modu3 CRT.
Niestety - im wy?ej pod wzgledem prostoty programowania, wiecej mo?liwo?ci
dostepnych w danym module, obiekcie itp - tym wieksze zasoby komputera s?
potrzebne do wykonania produktu wynikowego.

Mariusz Kruk

5/1/2007 7:56:00 PM

0

epsilon$ while read LINE; do echo ">$LINE"; done < Rafa3
>M. Kruk jak zwykle bawi sie w zagadki nie umiej?c odpowiedziea na proste
>pytanie... :P

Chce ci sie robia za interfejs do google'a?

>Wielko?a pliku wykonywalnego wynika z narzutu bibliotek do3?czanych do
>niego, umo?liwiajace wykonanie za3o?onych w nim dzia3an. Je?li np w Pascalu
>chcesz napisaa hello world i do3?czysz do programu biblioteke CRT a z niej
>u?yjesz jedynie procedury gotoxy, to niestety do pliku wynikowego trafi nie
>tylko samo gotoxy, ale równie? ca3y skompilowany modu3 CRT.

Chyba zatrzyma3e? sie przed wymy?leniem dynamicznie 3adowanych
bibliotek.

--
\.\.\.\.\.\.\.\.\.\.\.\.\.\ I szary cz3owiek nabiera kolorów przy czar-
..\.Kruk@epsilon.eu.org.\.\. nym charakterze.(Wojtek Moszko)
\.http://epsil...\.\
..\.\.\.\.\.\.\.\.\.\.\.\.\.

Jacek Czerwinski

5/1/2007 9:45:00 PM

0

Dnia Tue, 1 May 2007 21:55:35 +0200, Mariusz Kruk napisa3(a):

> epsilon$ while read LINE; do echo ">$LINE"; done < Rafa3
>>M. Kruk jak zwykle bawi sie w zagadki nie umiej?c odpowiedziea na proste
>>pytanie... :P
>
> Chce ci sie robia za interfejs do google'a?
>
>>Wielko?a pliku wykonywalnego wynika z narzutu bibliotek do3?czanych do
>>niego, umo?liwiajace wykonanie za3o?onych w nim dzia3an. Je?li np w Pascalu
>>chcesz napisaa hello world i do3?czysz do programu biblioteke CRT a z niej
>>u?yjesz jedynie procedury gotoxy, to niestety do pliku wynikowego trafi nie
>>tylko samo gotoxy, ale równie? ca3y skompilowany modu3 CRT.
>
> Chyba zatrzyma3e? sie przed wymy?leniem dynamicznie 3adowanych
> bibliotek.

Akurat biblioteki dynamiczne nie za bardzo s? przyk3adem oszczednego u?ycia
RAM-u. U?ycie, rzek3e? , funkcji gotoxy warto?ci 0,5kB, z koniecznym i
automatycznie poci?ganym modu3em inicjuj?cym 5kB dawa3o w statycznych
bilbiotekach 5,5kB (oczywi?cie przyk3adowo). Ale je?li sa one w DLL 'wagi'
1.5MB, uruchamiany jest ca3y DLL.

Na to dochodzi postep w kontrukcji kompilatorów (C/C++) i linkerów
(bardziej precyzyjnie docinaj?cych modu3y), wiec to sie troche poprawia,
ale wolniej ni? rosn? objeto?ci pakietów o wiekszych mozliwo?ciach.

Marcin 'Qrczak' Kowalczyk

5/1/2007 9:55:00 PM

0

Dnia 01-05-2007, wto o godzinie 23:45 +0200, Jacek Czerwinski
napisal(a):

> Akurat biblioteki dynamiczne nie za bardzo sa przykladem oszczednego
> uzycia RAM-u. Uzycie, rzekles , funkcji gotoxy wartosci 0,5kB, z
> koniecznym i automatycznie pociaganym modulem inicjujacym 5kB dawalo w
> statycznych bilbiotekach 5,5kB (oczywiscie przykladowo). Ale jesli sa
> one w DLL 'wagi' 1.5MB, uruchamiany jest caly DLL.

Co to znaczy „uruchamiany”? W normalnym systemie operacyjnym kod
biblioteki nie jest ladowany do pamieci od razu, tylko po kawalku
ladowany jest ten kod, który jest uzywany.

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.p...

Mariusz Kruk

5/1/2007 10:00:00 PM

0

epsilon$ while read LINE; do echo ">$LINE"; done < Jacek Czerwinski
>>>M. Kruk jak zwykle bawi sie w zagadki nie umiej?c odpowiedziea na proste
>>>pytanie... :P
>>
>> Chce ci sie robia za interfejs do google'a?
>>
>>>Wielko?a pliku wykonywalnego wynika z narzutu bibliotek do3?czanych do
>>>niego, umo?liwiajace wykonanie za3o?onych w nim dzia3an. Je?li np w Pascalu
>>>chcesz napisaa hello world i do3?czysz do programu biblioteke CRT a z niej
>>>u?yjesz jedynie procedury gotoxy, to niestety do pliku wynikowego trafi nie
>>>tylko samo gotoxy, ale równie? ca3y skompilowany modu3 CRT.
>>
>> Chyba zatrzyma3e? sie przed wymy?leniem dynamicznie 3adowanych
>> bibliotek.
>
>Akurat biblioteki dynamiczne nie za bardzo s? przyk3adem oszczednego u?ycia
>RAM-u.

Zauwa?, ?e nie by3o mowy o u?yciu pamieci, tylko o rozmiarach plików
wykonywalnych.

--
\.\.\.\.\.\.\.\.\.\.\.\.\.\ I am Leia of Borg. I'd rather assimilate a
..\.Kruk@epsilon.eu.org.\.\. Wookie!
\.http://epsil...\.\
..\.\.\.\.\.\.\.\.\.\.\.\.\.

Wiktor S.

5/1/2007 10:12:00 PM

0

> Programowaniem zajmuje sie jedynie hobbystycznie, jednak od d3u?szego
> czasu nurtuje mnie pytanie: dlaczego pliki wykonywalne we
> wspó3czesnych pecetach s? takie du?e? Pamietam gdy na?cie lat temu
> grzeba3em w asemblerze mikrokomputera Commodore64, to ca3y system
> operacyjny zajmowa3 kilka kilobajtów. Gra wraz z grafikami
> kilkadziesi?t, a kilkaset kilobajtów stanowi3o zasoby wrecz
> niewyobra?alne. Obecnie prosty program w C typu hello world po
> skompilowaniu i optymalizacji zajmuje kilka KB. Z czego wynika taki
> du?y narzut kodu?

1. nag3ówek PE pliku EXE swój kilobajt zajmuje, nazwijmy to "kosztem sta3ym"
2. narzut "runtime'a" - kod inicjalizuj?cy, obs3uga wyj?tków itp. - dodawane
przez kompilator do ka?dego exe.
3. je?li wy?wietlamy hello world z poziomu asemblera, to zajmie nam to ma3o.
ale je?li wywo3ujemy np. printf()-a, to oprócz kodu wy?wietlaj?cego ten
napis ci?gniemy za sob? ca3y kod formatuj?cy integery, floaty - wszystko, co
ten printf() obs3uguje.
4. narzut bibliotek - w zale?no?ci od opas3o?ci u?ywanych przez nas
bibliotek i sprytno?ci linkera, aby wyrzuca3 niewykorzystywane funkcje - im
wiecej dajemy "include'ów" i im wiecej bibliotek podlinkowujemy, tym wiecej
kodu znajdzie sie w exeku - z czego wiekszo?ci zazwyczaj nawet nie
wykorzystujemy.

Z drugiej strony, exeki kompilowane pod .Net s? bardzo ma3e - dlatego, ?e
wszystkie biblioteki s? we "frameworku", a nie wlinkowywane w exe.


--
Azarien

Jacek Czerwinski

5/1/2007 10:31:00 PM

0

Dnia Tue, 1 May 2007 23:59:59 +0200, Mariusz Kruk napisa3(a):

> epsilon$ while read LINE; do echo ">$LINE"; done < Jacek Czerwinski
>>>>M. Kruk jak zwykle bawi sie w zagadki nie umiej?c odpowiedziea na proste
>>>>pytanie... :P
>>>
>>> Chce ci sie robia za interfejs do google'a?
>>>
>>>>Wielko?a pliku wykonywalnego wynika z narzutu bibliotek do3?czanych do
>>>>niego, umo?liwiajace wykonanie za3o?onych w nim dzia3an. Je?li np w Pascalu
>>>>chcesz napisaa hello world i do3?czysz do programu biblioteke CRT a z niej
>>>>u?yjesz jedynie procedury gotoxy, to niestety do pliku wynikowego trafi nie
>>>>tylko samo gotoxy, ale równie? ca3y skompilowany modu3 CRT.
>>>
>>> Chyba zatrzyma3e? sie przed wymy?leniem dynamicznie 3adowanych
>>> bibliotek.
>>
>>Akurat biblioteki dynamiczne nie za bardzo s? przyk3adem oszczednego u?ycia
>>RAM-u.
>
> Zauwa?, ?e nie by3o mowy o u?yciu pamieci, tylko o rozmiarach plików
> wykonywalnych.

Strzelmy: 120kB apliakcji MFC linkowanej statycznie lub 50kB jak
dynamicznie+280kB DLL (bo jest monolitem, u?ywasz czy nie). Gdyby apliakcji
by3o 5, by3by oczywisty zysk na dynamicznej.

Niektóre frameworki (z nazw? Fast Light) wrecz sugeruj? statyczny sposób
u?ycia w3a?nie z tych wzgledów. 'Modne' programowanie C++ template te? jest
w tym sensie najcze?ciej statyczne (mam ?wiadomo?a ró?nic).

?e niby DLL mam bya 1 w systemie i w tym ma byc oszczedno?a... mi3y ale
czesto martwy postulat (DLL hell). W3a?nie na jutro dokumentuje dla
producenta taki error.

Jacek Czerwinski

5/1/2007 10:34:00 PM

0

Dnia Tue, 01 May 2007 23:54:56 +0200, Marcin 'Qrczak' Kowalczyk napisau(a):

> Dnia 01-05-2007, wto o godzinie 23:45 +0200, Jacek Czerwinski
> napisau(a):
>
>> Akurat biblioteki dynamiczne nie za bardzo sa przykuadem oszczednego
>> uyycia RAM-u. Uyycie, rzekueu , funkcji gotoxy wartouci 0,5kB, z
>> koniecznym i automatycznie pociaganym moduuem inicjujacym 5kB dawauo w
>> statycznych bilbiotekach 5,5kB (oczywiucie przykuadowo). Ale jeuli sa
>> one w DLL 'wagi' 1.5MB, uruchamiany jest cauy DLL.
>
> Co to znaczy ?uruchamiany?? W normalnym systemie operacyjnym kod
> biblioteki nie jest uadowany do pamiæci od razu, tylko po kawauku
> uadowany jest ten kod, który jest uyywany.
uadowany jest moduu w tym sensie, w jakim go zrobiu linker. Jeuli linker
zrobiu mniej-wiæcej monolit, to jest jednostka uadowania. Myulæ (nie mam
dowodów) ye równie duyo lub wiæcej jest nieoptymalizowanych DLL z
nieoptymalizujacych tego kompilatorów/linkerów (lub bo ktos nie dau
odpowienich wsadów).
Loader nie ma yadnego prawa (nie wyobrayam tego sobie) zauadowania czæuci
(tak pojætego) moduuu, musi cauoua.

yeby byuo jasne: tu moduu czæsto nie pokrywa siæ z moduuem eróduowym. Wiele
moduuów eróduowych tworzy .... pieron wie... nazwijmy pakiet uyytkowy,
stajacy siæ moduuem linkingu/loadera.

Jeuli masz jakieu fakty co do 'przyjæcia rynkowego' optymalizujacych
linkerów, chætnie usuyszæ... Ja widze radykalne skoki objætouci
zauadowanego programu jak dochodzi nowy DLL do projektu.


Z drugiej strony w suowach "kod biblioteki nie jest uadowany do pamiæci od
razu, tylko po kawauku uadowany jest ten kod, który jest uyywany." moyesz
miea na myuli managera pomiæci wirtualnej (stron), ale nawet dla czæuci nie
aktywnej w ramie zaszedu proces uadowania.

Stachu 'Dozzie' K.

5/1/2007 10:54:00 PM

0

On 01.05.2007, Jacek Czerwinski <x@y.z.pl> wrote:
> Dnia Tue, 01 May 2007 23:54:56 +0200, Marcin 'Qrczak' Kowalczyk napisau(a):
>
>> Dnia 01-05-2007, wto o godzinie 23:45 +0200, Jacek Czerwinski
>> napisau(a):
>>
>>> Akurat biblioteki dynamiczne nie za bardzo sa przykuadem oszczednego
>>> uýycia RAM-u. Uýycie, rzekueú , funkcji gotoxy wartoúci 0,5kB, z
>>> koniecznym i automatycznie pociaganym moduuem inicjujacym 5kB dawauo w
>>> statycznych bilbiotekach 5,5kB (oczywiúcie przykuadowo). Ale jeúli sa
>>> one w DLL 'wagi' 1.5MB, uruchamiany jest cauy DLL.
>>
>> Co to znaczy Yuruchamiany!? W normalnym systemie operacyjnym kod
>> biblioteki nie jest uadowany do pamiaci od razu, tylko po kawauku
>> uadowany jest ten kod, który jest uýywany.
> uadowany jest moduu w tym sensie, w jakim go zrobiu linker. Jeúli linker
> zrobiu mniej-wiacej monolit, to jest jednostka uadowania. Myúla (nie mam
> dowodów) ýe równie duýo lub wiacej jest nieoptymalizowanych DLL z
> nieoptymalizujacych tego kompilatorów/linkerów (lub bo ktos nie dau
> odpowienich wsadów).
> Loader nie ma ýadnego prawa (nie wyobraýam tego sobie) zauadowania czaúci
> (tak pojatego) moduuu, musi cauoúa.

Owszem, ma prawo. Pod Linuksem na ten przyk3ad odczytywany jest nag3ówek
biblioteki dynamicznej, w którym jest tablica eksportowanych symboli.
Z takiej tablicy odczytywane jest, ile zawarto?ci pliku nale?y zamapowaa
do pamieci procesu u?ywaj?cego biblioteki.

Poza tym pomijasz fakt, ?e kod biblioteki to na ogó3 kod
readonly-executable, wiec mo?e bya bezkarnie u?ywany przez kilka ró?nych
procesów, wiec dobrze skompilowana biblioteka jest 3adowana jeden raz,
a u?ywana przez wiele procesów jednocze?nie.

--
Secunia non olet.
Stanislaw Klekot