- 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.