Co jest aktualnie automatycznie dodawane do kompilowanej aplikacji?

0

Czy to konieczne na zwykłą aplikację konsolową na 10 linijek dostawać plik 1,8MB. Środowisko Devcpp właśnie mi takie wywaliło. To w delphi 7 aplikacja okienkowa z jeszcze ilomaś tam komponentami, zmiennymi itp. kompiluje mi na 400KB. Pamiętam jak się uczyłem (turbo) Pascala tam wychodziły pliki po kilka KB przy kodzie na kilkaset linijek. Czy teraz aby osiągnąć zwykłe programy początkująco-edukacyjne trzeba aż tyle miejsca marnować czy da się coś z tym zrobić?

1
Brunatny Szewc napisał(a):

Czy to konieczne na zwykłą aplikację konsolową na 10 linijek dostawać plik 1,8MB.

Przy domyślnych ustawieniach, do pliku wykonywalnego dodawane są symbole debuggera. Jeśli faktycznie są one dodawane, to stanowią 80-90% objętości pliku wykonywalnego. Liczy się też rozmiar RTL-a, dane dodawane do zasobów oraz mnóstwo innych elementów.

Pamiętaj też o tym, że nawet jeśli rozmiar początkowy wynosi np. 2MB (wersja release) to po dopisaniu nawet tysięcy linijek kodu, rozmiar pliku wykonywalnego nie wzrośnie znacząco. Chyba że dodasz nowe biblioteki, zasoby itd.

Środowisko Devcpp właśnie mi takie wywaliło.

Środowisko niczego Ci nie dodało do tego pliku – kompilacją i generowaniem plików wykonywalnych zajmuje się kompilator, nie IDE. Zresztą, zmień IDE, bo Dev-C++ nie jest już wspierane.

To w delphi 7 aplikacja okienkowa z jeszcze ilomaś tam komponentami, zmiennymi itp. kompiluje mi na 400KB. Pamiętam jak się uczyłem (turbo) Pascala tam wychodziły pliki po kilka KB przy kodzie na kilkaset linijek.

Bo jest cholernie stare i ubogie. RTL zajmuje tyle co nic, VCL z kolei kilkadziesiąt razy mniej niż w bieżących wersjach (bo o wiele uboższe i wyłącznie jednoplatformowe). Nie ma się nad czym rozwidzić – chcesz cokolwiek porównywać, to porównuj bieżące technologie, a nie te archaiczne, o których już ludzkość zapomniała.

Czy teraz aby osiągnąć zwykłe programy początkująco-edukacyjne trzeba aż tyle miejsca marnować czy da się coś z tym zrobić?

Oczywiście – można zmienić ustawienia projektu i kompilować bez symboli debuggera (o ile nie będzie się chciało tego programu debugować). Można też podłubać w ustawieniach dotyczących optymalizacji (wolniejsze działanie kodu, ale mniejszy jego rozmiar).

Dziś rozmiar plików wykonywalnych nie ma większego znaczenia, dlatego nie ma sensu głowić się nad tym, jak zyskać megabajt czy dwa. Kompresja też raczej nie ma sensu (np. za pomocą UPX), bo tylko same problemy z antywirusami, a korzyści żadnych.

0

Mi na Linuxie aplikacja "na 10 linijek" skompilowana w GCC 8 waży 7kB.

0

Assembler i hello world w syscallu zajmie ci 40bajtów z nagłówkiem elfa.
Nie mówiąc o tym, że te syscalle cały czas są w systemie załadowane.

Ale libc biblioteka C bardzo dużo waży, symbole debugera, i nagłówek to chyba tyle.
Właściwie w produkcyjnym kodzie powinno się wycinać symbole debbugera, lub zaznaczać w kompilatorze żeby nie dodawał, gdyż dzięki temu łatwiej analizować kod, a niech się męczą :>

0

Duzy plik wynikowy moze byc tez efektem tego, ze biblioteki do tego pliku dolinkowane sa statycznie.

0

Dla mnie duży plik wykonywalny to co najmniej kilkaset megabajtów. Coś jak lazarus.exe217MB.

To że aplikacja zajmuje ”dużo” miejsca, wcale nie oznacza, że będzie działać wolniej.

0
furious programming napisał(a):

To że aplikacja zajmuje ”dużo” miejsca, wcale nie oznacza, że będzie działać wolniej.

Nie mniej jednak czasy ładowania aplikacji (szczególnie jeśli ktoś sobie zechce uruchamiać program z lokalizacji sieciowej) może się wydłużyć.
Ale ogólnie można powiedzieć, że w dzisiejszych czasach nie ma się co przejmować rozmiarem exe'ców, gdzie niektóre gry mają po 50GB :)

1

@Mr.YaHooo: szkoda że takich tematów nigdy nie zakładają użytkownicy, którzy mają faktyczny powód do odchudzania i przyspieszania ładowania plików wykonywalnych. Zwykle autor takiego wątku w ogóle nie wie co znajduje się w pliku wykonywalnym i dlaczego rozmiar jest taki a nie inny. A do tego porówuje się technologie powstałe na przestrzeni 50 lat.

1

@furious programming niestety. Wystarczyłoby poczytać nawet helpa i by było wiadomo co jest nie tak. Warto popatrzeć na opcje projektu i od razu widać ile w większości zbędnych modułów jest ładowane z VCL'a w większości programów. A każdy moduł zwiększa rozmiar wynikowego pliku, dodatkowo symbole debuggera i rozmiar rośnie lawinowo.

1 użytkowników online, w tym zalogowanych: 0, gości: 1