Cześć,
jest jakieś narzędzie / sposób żeby dowiedzieć się ile miejsca w skompilowanym pliku exe zajmują konkretne moduły z sekcji uses?
Strasznie duże pliki exe generuje te nasze Delphi co wszyscy wiedzą ale być może mógłbym z czegoś zrezygnować lub zrobić to inaczej gdybym wiedział co tak bardzo wpłynęło na wielkość skompilowanego pliku.
Pozdrawiam
A ile waży plik? co masz na myśli jako uses?
W C i C++ jest o tyle dobrze, że mogą sobie aplikacje dynamicznie większość bibliotek załadować to mało ważą, jak tu wszystko w exece wkompilujesz, a musisz jak system tego nie posiada to aplikacja urośnie, można skompresować exe plik.
Które Delphi?
Bo o ile pamiętam, to Delphi 7 Personal robiło pliki *.exe na ok. 500kB.
W Delphi bez obsługi unicode pliki nie były aż tak duże, w nowych wersjach są naprawdę pokaźne. Zdaje sobie z tego sprawę, dlatego właśnie pytam o narzędzie do analizy wielkości składników gotowego pliku exe.
Co do rozkładania gotowego rozwiązania na np. biblioteki. Moje pytanie dotyczy właśnie takiego prostego programu w którym rozkładanie na składniki nie ma żadnego sensu. Jednak w programie tym używam kilku modułów np. Firedac. Gdybym wiedział jaki mają wpływ na wielkość pliku wynikowego to np. mógłbym zamienić Firedac na UniDac aby uzyskać mniejszy plik. Tylko tak dywaguję.
Po zainstalowaniu JCL/JVCL w menu mam coś takiego Project->Analyze project
Z pliku MAP tez chyba mozna to odczytac
Generalnie ślepa uliczka to szukanie !
jak CI zależy na wielkosci to skompresuj EXE https://upx.github.io/
nm <nazwaaplikacji.exe.o> radare2 ma dużo takich aplikacji do analizy binarek, ghidra jest najlepszym darmowym narzędziem do analizy resztę musisz sam zrobić, bo to trochę pracy.
@robertz68: przejdź na gamedev, np. czyste C/Pascal + SDL2. W moim przypadku, kilkanaście tysięcy linijek kodu gry kompiluje się do 130KB w debugu i do 90KB w release — problem dużych exeków zażegnany bezpowrotnie. :D
A tak na poważnie — w temacie narzędzi nie będę się wypowiadał, bo nie mam raczej nic odpowiedniego i dobrego do polecenia, ale chciałbym skomentować Twoje słowa. Chodzi o dwa poniższe fragmenty.
robertz68 napisał(a):
Co do rozkładania gotowego rozwiązania na np. biblioteki. Moje pytanie dotyczy właśnie takiego prostego programu w którym rozkładanie na składniki nie ma żadnego sensu.
Podział kodu programu nie ma żadnego sensu, jeśli jedynym tego powodem jest chęć zmniejszenia rozmiaru pliku wykonywalnego. Pamiętaj, że każdy plik DLL, do którego wydzielisz fragmenty kodu, dostaje swoją kopię RTL-a, a to powoduje, że efekt jest odwrotny — zmniejszasz rozmiar exe, jednocześnie zwiększając rozmiar całego pakietu plików aplikacji. Przy czym tak czy siak w głównym programie będziesz musiał do uses dodać te ”opasłe” moduły, aby móc używać tych samych typów danych, których wymaga API z bibliotek. Dodatkowo, bezsensowny podział programu na biblioteki powoduje, że tworzy się kolejne miejsca do wystąpienia problemów. Braknie jednej biblioteki i dupa — program stanie się bezużyteczny.
Biblioteki DLL tworzy się po to, aby ich zawartość była uniwersalna, mogąca być wykorzystaną również przez inne aplikacje, bez względu na język programowania, w których zostały zaprogramowane. Ich przeznaczeniem jest udostępnianie funkcjonalności oraz zasobów, i tego trzeba się trzymać.
Druga sprawa to UPX — tutaj też możesz dostać efekt odwrotny od zamierzonego. W przypadku zwykłego exe, system może załadować do pamięci tylko potrzebne fragmenty. Jeśli plik wykonywalny jest skompresowany, to musi go najpierw zdekompresować w całości, a to tylko wydłuży czas rozruchu programu. Im większy plik wykonywalny, tym gorszy rezultat.
Jednak w programie tym używam kilku modułów np. Firedac. Gdybym wiedział jaki mają wpływ na wielkość pliku wynikowego to np. mógłbym zamienić Firedac na UniDac aby uzyskać mniejszy plik. Tylko tak dywaguję.
To też brzmi trochę bezsensownie. Twoim priorytetem powinne być moduły, które zapewniają Ci potrzebną funkcjonalność w formie stabilnej, bogatej i wygodnej do użycia. Czyli powinieneś wybrać to, co jest lepsze, a nie co mniej będzie ważyć na dysku.
takie pytanie pomocnicze - na dyskietkach będziesz ten program rozdawał czy co?
Po kolei:
Sztuką dla mnie jest aby wiedzieć co o ile powiększa plik a widzę że można się mocno zaskoczyć.
robertz68 napisał(a):
- narzędzie Project Analyzer pokazuje użycie modułów których kompletnie się nie spodziewałem?
To pytanie czy stwierdzenie? ;)
Nie znam tego narzędzia, ale na tej liście mogą i pewnie znajdują się absolutnie wszystkie moduły, które będą kompilowane, a nie tylko te, które jawnie masz w uses. Czyli np. dodajesz SysUtils, a tym analizatorze pokaże SysUtils i wszystkie moduły, które SysUtils ma w swoich uses, a potem kolejne i kolejne, czyli pełne drzewo (wyświetlone w formie płaskiej listy).
- zdarzało mi się używać UPX-a ale efekt jest taki jak opisuje @furious programming czyli plik jest mniejszy ale się dłużej uruchamia, może nie u mnie bo nadrabiałem to mocą sprzętu ale program uruchamiany na jakimś celeronie startował wyraźnie dłużej. Poza tym niektóre antywirusy nie są "zadowolone" z takiej kompresji. Skończyłem z tym lata temu.
Niedawno, jeden z użytkowników podał, że UPX bywa przydatny w oprogramowaniu serwerowym. Program jest skompresowany UPX-em, a podczas uruchamiania system go w całości dekompresuje i wrzuca do RAM-u, dzięki czemu w trakcie działania programu, system już niczego nie będzie musiał doładowywać. Nie znam się na serwerach, stąd trudno mi powiedzieć cokolwiek na temat benefitów takiego rozwiązania.
- rozkładanie małego programu na biblioteki jak pisałem nie ma sensu, sens jest w wielkich rozwiązaniach i ładowaniu dynamicznym aktualnie potrzebnej funkcjonalności. Ale to mnie prawie nigdy nie dotyczy,
Ludzie wykorzystują DLL-e do różnych celów — zwykle do wydzielenia i podzielenia się funkcjonalnością z innymi programami, ale też do tworzenia małych, wymiennych i łatwo zarządzanych pluginów, paczek zasobów graficzych, plików lokalizacyjnych (translacja UI) itd. Jest dużo różnych przypadków, w których pliki DLL dają całkiem sporą wygodę i elastyczność, dzięki czemu faktycznie jest sens ich używania. Niestety chęć zmniejszenia rozmiaru exe jest absolutnym błędem, a końcowy efekt jest odwrotny od zamierzonego — jak pisałem w poprzednim poście, jeden plik maleje, a masa innych puchnie.
- co do zastąpienia jakiegoś modułu innym, nie chodzi mi o użycie czegoś dużo gorszego. Podam przykład, potrzebuję grida, mogę użyć coś z DevExpressa i powiększyć wielkość pliku exe dwukrotnie albo użyć np. grida scalabium. Exe prawie nie urośnie a mi to może wystarczyć (i prawie zawsze wystarcza).
Dla mnie coś takiego nie jest dobrym podejściem — nie lubię tworzenia niepotrzebnych zależności. Mało tego, staram się unikać dodatkowych zależności jak ognia. Jeśli potrzebuję jakąś kontrolkę, ale ta z LCL jest biedna, to zamiast szukać w necie paczki z taką, która będzie mi pasować, tworzę sobie swoją na podstawie tej bazowej i dodaję do niej interesujące mnie ficzery. Ostatecznie mam to co chcę, wygląda i działa tak jak chcę, dodatkowa zalezność nie powstaje. A w razie gdybym potrzebował coś jeszcze, to sobie swoją kontrolkę rozwijam dalej (zamiast znów szukać cudzej kontrolki spełniającej wymagania).
Podobnie z obecnym projektem, czyli z grą wideo — jedyne czego używam to wbudowanego modułu System oraz SDL2, natomiast modułów z FCL i LCL nie dołączam. Przecież nie potrzebuję dołączać np. modułu Math żeby mieć dostęp do stałej Pi czy funkcji takich jak Min, Max, EnsureRange, skoro mogę sobie takie napisać w pół minuty. Poza tym benefit też jest taki, że takie podstawowe funkcje tworzę konkretnie dla własnych aliasów typów danych oraz wykluczam techniki, z których nie chcę korzystać (np. domyślne wartości parametrów funkcji, bo to dla mnie obfuskacja kodu, a nie ułatwienie). No ale to trochę inny temat.
W każdym razie, jeśli dany pakiet zapewnia Ci potrzebną funkcjonalność, to z niej korzystaj, nie patrząc na to o ile spuchnie exe. Ogranicz zależności do minimum, bo one mogą Cię znacznie mocniej kopnąć niż nieco większy plik wykonywalny. Webowcy akurat powinni sporo wiedzieć na ten temat. :D
Sztuką dla mnie jest aby wiedzieć co o ile powiększa plik a widzę że można się mocno zaskoczyć.
Może sprawdź sobie prekompilowane pliki obiektowe poszczególnych modułów? Kompilator tworzy je dla każdego używanego modułu, aby kolejne kompilacje były szybkie. Zobacz ile ważą te pliki, być może pozwolą one określić przybliżony wzrost wagi pliku wykonywalnego.
Trzeba jednak zaznaczyć, że ich rozmiar może być (i zapewne będzie) różny dla różnych ustawień kompilacji. Na przykładzie swojej gry i FPC (co może odbiegać od Delphi i Twojego projektu), dzięki użyciu konkretnych ustawień kompilacji dla wersji release (brak ficzerów do debugowania, odblokowaniu mocnych optymalizacji, smart linkowania itp. itd.), pliki obiektowe ważą dużo mniej niż dla wersji debug (nawet o kilkadziesiąt procent) i finalny plik wykonywalny również waży mniej.
Wtrącę swoje 3gr :)
Nie zawsze mały rozmiar exe, co często skutkuje wieloma dodatkowymi plikami, jest najważniejszy. Ja wolę mieć jedyny, ale większy plik exe, aby dystrybucja tego pliku była jak najprostsza, bez potrzeby instalacji.
Podam ekstremalny (nie mój) przykład dużego pliku...
Używam programu eDek (do e-deklaracji). Tam jest tylko jedynie plik EXE o rozmiarze ponad 560 MB ! Przypuszczam, że rozmiar wynika z tego, że wszystkie formularze/deklaracje są "upakowane" w EXE, zamiast umieszczać setki plików osobno. Sam program uruchamia się w ułamku sekundy nawet na słabszym sprzęcie (Intel i3)
Przydal by sie lepszy opis bo to jakis BLOG
https://technical-qa.com/how-is-an-exe-loaded-into-memory/
How is an exe loaded into memory?
1 Answer. Under OS X, Windows, Linux, and iOS executables are not loaded into RAM when executed. Instead the executable is mapped into the virtual address space of the process.
to by tłumaczyło dlaczego 560 MB EXE uruchamia sie w ulamek sekundy
Coś przecież musi być ładowane do RAM-u. Gdyby system tylko mapowanie wykonał i nic nie załadował do pamięci (w formie jakiegoś cache), to wykonywanie kodu wymagałoby ciągłego rżnięcia po dysku, co byłoby niewydajne (szczególnie w przypadku HDD). Trzeba by zaglądnąć głębiej, bo coś mi się wydaje, że wykonywanie kodu programów na współczesnych systemach operacyjnych jest znacznie bardziej skomplikowane. :D