Dlaczego rozmiary programów są tak duże?

Jeśli spojrzymy na starodawny program Netscape Navigator lub wczesną wersję Microsoft Word, te programy miały mniej niż 50 MB. Teraz, gdy instaluję Google Chrome, jest to 200 MB, a wersja Slacka na komputer to 300 MB. Czytałem o pewnej zasadzie, że programy zajmą całą dostępną pamięć, bez względu na to, ile to kosztuje, ale dlaczego?

Dlaczego obecne rozmiary programów są tak duże w porównaniu do 10 czy 15 lat temu? Programy nie wykonują znacznie więcej funkcji i nie wyglądają inaczej. Co to jest teraz świnia zasobów?

„Wyglądać inaczej” to kwestia percepcji. Dzisiejsza grafika musi wyglądać dobrze w zupełnie innych rozdzielczościach ekranu niż kiedyś, w wyniku czego obraz 100 x 100, który kiedyś był wystarczająco dobry dla logo, wyglądałby teraz strasznie tandetnie. Musiał zostać zastąpiony obrazem tej samej rzeczy o wymiarach 1000 x 1000, czyli 100 razy. (Wiem, że zamiast tego można użyć grafiki wektorowej, ale to tylko podkreśla tę kwestię - kod renderujący grafikę wektorową musiał zostać dodany do systemów, które wcześniej go nie potrzebowały, więc jest to tylko kompromis z jednym rodzajem zwiększenia rozmiaru do innego.)

„Praca inaczej” jest również kwestią percepcji. Dzisiejsza przeglądarka robi masowo więcej niż jedną z 1995 roku. (Spróbuj pewnego dnia w Internecie surfować po historycznym laptopie - okaże się, że jest prawie bezużyteczny.) Niewiele z nich jest używanych bardzo często, a ich użycie może być zupełnie nieświadome 90 % z nich, ale oni tam są.

Do tego oczywiście ogólna tendencja do spędzania mniej czasu na optymalizacji rzeczy pod kątem miejsca, a więcej na wprowadzaniu nowych funkcji. Jest to naturalny efekt uboczny większych, szybszych i tańszych komputerów dla wszystkich. Tak, możliwe byłoby pisanie programów, które są tak wydajne pod względem zasobów jak w 1990 roku, a wynik byłby oszałamiająco szybki i szybki. Ale nie byłoby to już opłacalne; Twoja przeglądarka zajmie dziesięć lat, do tego czasu wymagania ulegną całkowitej zmianie. Ludzie zwykli programować ze szczególną dbałością o wydajność, ponieważ powolne, małe maszyny z przeszłości były do ​​tego zmuszone, a wszyscy inni też to robili. Gdy tylko to się zmieniło, wąskie gardło sukcesu programu zmieniło się z możliwości uruchomienia w ogóle na działaniecoraz więcej błyszczących rzeczy i właśnie tam jesteśmy.

Jeśli porównasz Netscape Navigator do nowoczesnej przeglądarki, istnieje ogromna różnica w funkcjonalności. Wystarczy porównać specyfikację HTML 3.2 (51 stron, kiedy robię podgląd wydruku) z bieżącą specyfikacją HTML (wersja PDF to 1155 stron). To 20-krotny wzrost wielkości.

Netscape Navigator nie miał DOM i CSS! Nie wprowadzono żadnych dynamicznych zmian w dokumencie, JavaScript modyfikujący DOM ani arkusze stylów. Brak kart. Brak dźwięku lub obrazu. Nowoczesna przeglądarka jest znacznie bardziej złożonym programem.

Jednym z powodów jest to, że dane spakowane w aplikacjach są większe, ponieważ mają wyższą rozdzielczość i jakość. Ikona w czasach Netscape miała co najwyżej 32 x 32 piksele, z co najmniej 8-bitową głębią (prawdopodobnie tylko 4), podczas gdy teraz jest prawdopodobnie czymś w rodzaju 64 x 64 i jest w prawdziwym kolorze z przezroczystością, co oznacza 32-bitową głębię. To 16 razy większy. A miejsce jest tak tanie, że ludzie często nawet nie zawracają sobie głowy sprawdzaniem opcji „skompresowanej” podczas generowania PNG.

Innym powodem jest to, że obecnie aplikacje niosą ze sobą zadziwiającą ilość danych, czego nie zrobiły starsze aplikacje. Istnieją dziś aplikacje dostarczane wraz z prezentacją „wprowadzenie” na wideo .

Innym powodem jest to, że obecnie języki programowania łączą się z bogatymi środowiskami wykonawczymi, które są dość duże, do 100 MB każdy. Nawet jeśli nie korzystasz ze wszystkich funkcji środowiska wykonawczego, nadal musisz spakować całą aplikację.

Ale głównym powodem jest to, że dzisiaj istnieje mnóstwo bibliotek, które możemy wykorzystać w naszych aplikacjach, i opracowaliśmy kulturę korzystania z bibliotek, aby uniknąć ciągłego ponownego wymyślania koła. Oczywiście, kiedy zaczniesz korzystać z bibliotek, pojawi się kilka pytań, a my wypracowaliśmy zwyczaj udzielania najbardziej liberalnych odpowiedzi:

• Czy warto dołączyć kolejną bibliotekę, jeśli będzie używana tylko przez jedną z moich funkcji? - tak

• Czy warto dołączyć kolejną bibliotekę, jeśli potrzebuję tylko niewielkiego podzbioru całego bogactwa funkcji oferowanych przez tę bibliotekę? - tak

• Czy warto dołączyć kolejną bibliotekę, jeśli jej włączenie uratuje mnie od 2 dni pracy? - tak

• Czy warto uwzględnić wiele bibliotek, które służą mniej więcej temu samemu celowi, tylko dlatego, że różni programiści na mojej liście płac znają się już na różnych bibliotekach? - tak

  (Uwaga: obserwuję te tendencje, nie składam żadnego oświadczenia, czy się z nimi zgadzam, czy nie).

Innym powodem, o którym warto wspomnieć, jest to, że próbując zdecydować, której aplikacji użyć spośród kilku opcji, niektórzy użytkownicy uważają, że ta, która zajmuje więcej miejsca, będzie miała więcej funkcji, będzie miała bardziej wyszukaną grafikę itp. (Co jest oczywiście kompletnym nonsensem .)

Podsumowując, czy oprogramowanie zachowuje się jak gaz? Czy zajmuje to całą dostępną przestrzeń? W pewnym sensie tak, ale nie w niepokojącym stopniu. Jeśli spojrzymy na to, co zajmuje najwięcej miejsca na naszych dyskach, dla większości z nas odpowiedź brzmi: nie są to aplikacje, ale zdecydowanie media takie jak filmy i muzyka . Oprogramowanie nie rozwija się w tym samym tempie, co pojemność pamięci, i jest mało prawdopodobne, że kiedykolwiek się zwiększy, więc w przyszłości aplikacje prawdopodobnie będą stanowiły znikomy ułamek miejsca dostępnego dla użytkowników.

Oprócz innych anserów, 10 lat temu zwykle istniałyby osobne wersje dla wersji zlokalizowanych / międzynarodowych. Teraz ogólnie jest tak, że programy dołączą pełną obsługę lokalizacji do każdej wydanej wersji, która uzupełnia rozmiar programu.

Jednym z powodów są zależności. Program o bogatej funkcjonalności i dobrym wyglądzie wymaga wielu rzeczy - szyfrowania, sprawdzania pisowni, pracy z XML i JSON, edycji tekstu i wielu innych rzeczy. Skąd oni pochodzą? Może rzucisz własnym i utrzymasz je tak małe, jak to możliwe. Najprawdopodobniej korzystasz z komponentów stron trzecich (być może licencjonowanego na licencji MIT typu open source), które mają wiele funkcji, których tak naprawdę nigdy nie potrzebujesz, ale kiedy potrzebujesz jednej funkcji z komponentu innej firmy, często musisz nosić ze sobą cały komponent. Dodajesz więc coraz więcej zależności, a one same ewoluują i rozwijają Twój program, który zależy od nich.

Chociaż grafika / użyteczność są rzeczywiście czynnikami, to jest bardzo dużo tego, co zawiera biblioteka / nadmiar skompilowanego kodu.

Przykład tego, jak mały może być nadal kod: MenuetOS, pełny 64-bitowy system operacyjny z potężnymi aplikacjami, który mieści się na pojedynczej dyskietce.

Przykład tego, jak duży może być kod bez wyraźnego powodu: wykonałem proste wyjście tekstowe „Witaj, świecie!” ostatnio w Adzie. Skompilowany plik wykonywalny miał ponad 1 MiB !. Ten sam plik wykonywalny w asemblerze to po prostu KiB lub 2 (a większość z nich to plik wykonywalny, rzeczywisty działający kod to kilkadziesiąt bajtów).

To prawda, że ​​oprogramowanie musi być zbudowane tak, aby pasowało do dwóch rzeczy: użytkowników i dostępnego sprzętu. Program jest odpowiedni do swoich celów, jeśli robi to, czego chce użytkownik w odpowiednim czasie, korzystając ze sprzętu do dyspozycji użytkownika. No cóż. Ale w miarę jak sprzęt poprawia się zasadniczo we wszystkich mierzalnych wymiarach, rośnie liczba dyskretnych programów, które zmieniają się z niepasujących do pasujących - przestrzeń projektowa staje się większa:

• Języki wyższego poziomu umożliwiają wyrażanie pomysłów w krótszym czasie niż w przeszłości. I odwrotnie, ta obniżona złożoność umożliwia wyrażanie coraz bardziej złożonych pomysłów.
• Sprzedaż wiązana większej ilości danych z aplikacją może sprawić, że będzie ona natychmiast bardziej użyteczna. Na przykład prawdopodobnie nie potrwa długo, zanim aplikacje sprawdzające pisownię zostaną dołączone do każdego języka znanego ludzkości - w końcu to tylko kilka gigabajtów.
• Kompromisy sprzętowe umożliwiają programistom i użytkownikom większy wybór zasobów, na których im zależy. Zobacz na przykład FLAC / OGG vs WAV, SVG vs PNG, indeksy baz danych.
• Ludzkie interfejsy często wymieniają coś, co wcześniej stanowiłoby ogromną ilość sprzętu pod względem użyteczności. Antyaliasing, wysoka rozdzielczość, szybkie odświeżanie i przesuwanie pomiędzy dyskretnymi panelami - wszystko to zapewnia bardziej realistyczne, a zatem intuicyjne i możliwe do odniesienia, wrażenia.

Jest to zdecydowanie prawda w odniesieniu do aplikacji na Androida. Cztery lata temu prosta aplikacja zajmowała około 2-5 megabajtów. Obecnie prosta aplikacja zajmuje około 10-20 megabajtów.

Im więcej dostępnego miejsca, tym większy rozmiar aplikacji.

Myślę, że istnieją dwa główne powody w przypadku Androida:

• Google rozszerzyło platformę Android, dodało wiele nowych funkcji.

• Deweloperzy już się nie przejmują. Obrazy są zawarte w znacznie wyższej rozdzielczości (oczywiście zwiększone rozdzielczości ekranu smartfona), biblioteki innych firm są bezmyślnie uwzględnione.

Wiele z nich sprowadza się do czasu programisty i kosztu tego czasu. W czasach, gdy Visual Basic po raz pierwszy pojawił się na scenie, konkurował z C / C ++, a dużym wyzwaniem było to, że można napisać „Hello World” w ANSI C dla Windows w około 15 KB. Problem z VB polegał na tym, że zawsze miałeś albatross biblioteki wykonawczej 300K.

Teraz możesz 10-krotnie powiększyć swój program VB i nadal byłoby to tylko kilka K więcej, ale 10-krotnie większy niż twój program C / C ++ i patrzysz na kilka miesięcy rozwoju.

W końcu nadęty aplikacji to niewielka cena za ogromne skoki w produkcji deweloperskiej, obniżkę ceny i ogromny potencjał, który nigdy nie byłby możliwy w dawnych, ręcznie opracowanych czasach rozwoju; gdy programy były małe i szybkie, ale także słabe, niekompatybilne ze sobą, słabo wyposażone i kosztowne w rozwoju.

Z czasem potrzeby użytkowników ewoluują i stają się coraz bardziej wymagające, więc dostawcy / autorzy różnych programów są zmuszeni do zaspokojenia tych potrzeb w imię konkurencji.

Ale zaspokojenie nowej potrzeby oznacza często dodawanie nowego kodu. Nowy kod oznacza nowe luki do usunięcia. Naprawa nowych luk może dodać kod lub otworzyć drzwi do nowych luk.

Każda dodana funkcja zaspokajająca potrzeby użytkownika może wymagać większej mocy procesora dla szybkości (wszyscy narzekamy na szybkość tej lub innej przeglądarki), nowych zasobów graficznych dla lepszych efektów wizualnych ... itp.

Wszystko to oznacza dodawanie nowych warstw aplikacji (kodu), bezpieczeństwa, a czasem sprzętu.

Wiele rozmiarów pochodzi z wbudowanych bibliotek. Wiele aplikacji jest obecnie budowanych przy użyciu elektronu, który łączy ogromną ilość z aplikacją. Jeśli instalujesz aplikacje w systemie Linux, zwykle są one znacznie mniejsze, ponieważ duża część aplikacji jest już zainstalowana za pośrednictwem bibliotek współużytkowanych, z których korzystają także inne programy.

Jeśli podczas tworzenia oprogramowania potrzebujesz funkcji A, zaimportujesz moduł A *. A * może rozwiązać A, ale A * może rozwiązać problemy bardziej niż A, a A * może być duży. Wszystkie duże moduły tworzą duże oprogramowanie.

Może nie ten sam przypadek, ale coś w tym rodzaju: Jeśli po prostu chcesz wydrukować „hello world” na konsoli za pomocą Java, musisz zainstalować JRE (> 60 MB).

Jeśli przykład Javy nie jest dobry, wypróbuj ten: Jeśli oprogramowanie musi zalogować się do pliku, może użyć modułu rejestrującego, który może tworzyć dzienniki do bazy danych, przez sieć i niektóre inne funkcje, ale funkcje nigdy nie są używane w projekt.

Czytałem o pewnej zasadzie, że programy zajmą całą dostępną pamięć, bez względu na to, ile to kosztuje, ale dlaczego?

To nie do końca prawda. Systemy nie zwalniają pamięci, którą zużyły, dopóki system operacyjny nie znajdzie się pod presją pamięci. Jest to poprawa wydajności. Jeśli przeglądasz stronę z włączonymi obrazami, nawigujesz dalej. Możesz wrócić do poprzedniej wersji, dlatego ponownie potrzebujesz obrazu. Jeśli system operacyjny ma pamięć RAM, wyczyszczenie pamięci nie ma sensu, dopóki nie będziesz pewny, że nie będziesz jej potrzebować ponownie.

Natychmiastowe wyczyszczenie pamięci zabrałoby cykle procesora i przepustowość pamięci od użytkownika, gdy najprawdopodobniej chcą, aby na ekranie wyświetlane były szybko reagujące strony internetowe.

System operacyjny zajmie całą dostępną pamięć nieaplikacyjną, z której większość przeznaczona jest na pamięć podręczną systemu plików.

Zarządzanie pamięcią to trudny problem, ale przez cały czas pracują nad nią bardzo mądrzy ludzie. Celowo nie marnuje się niczego, a kluczowym celem jest zapewnienie bardzo responsywnego komputera.

Może być prawdą, że programy rozszerzają się, by zapełnić dostępną przestrzeń, podobnie jak zjawiska podmiejskie, w których dodaje się nowe pasy do zablokowanej sieci autostrady iw ciągu kilku lat ruch jest ponownie generowany.

Ale jeśli spojrzysz na to, może się okazać, że ich programy robią więcej rzeczy. Przeglądarki, na przykład, uruchamiają bardziej wyszukaną grafikę, mają zręczne narzędzia programistyczne, które nie istniały kilka lat temu, itp. Łączą się również z wieloma bibliotekami, czasami wykorzystując tylko niewielką część kodu. Tak więc chociaż programy mogą się zwiększać, aby zapełnić dostępną pamięć, niektóre z nich mogą być uzasadnione.

Biblioteki zbudowane na obiektach, które nie są zoptymalizowane, wymagają więcej pamięci do załadowania, zainstalowania i większej liczby cykli obliczeniowych do działania. Kod obiektowy jest w większości nadęty.

Wystarczy przejść przez uruchomiony standardowy kod C ++, aby zobaczyć wszystkie wywołania obiektów assert () ed, aby upewnić się, że są poprawnymi obiektami. Podczas projektowania warstwa po warstwie obiektów otaczających obiekty, podkłady są nadęte i nieprzezroczyste. Programiści stają się leniwi i przyjmują więcej obiektów, ponieważ jest to szybsze niż przeprojektowywanie tego, co jest ograniczone do wymaganej funkcjonalności. To naprawdę takie proste.

Rozważ rozmiar jądra Linux C, po prostu jądra, w porównaniu z wielkością niestandardowych aplikacji. Jądro może uruchomić całą maszynę. Ale nie został zbudowany tak szybko, jak aplikacje, aby uzyskać najlepszą funkcjonalność, potrzeba dużo czasu.