Jak to się zaczęło?
Ok roku 2007 zakupiłem swojego pierwszego laptopa, firmy Lenovo. Model 3000 N100, jak na tamte czasy zakup wydawał się odpowiedni biorąc pod uwagę moje potrzeby i cenę. W końcu Procesor Intel Celeron M, 512 MB Ramu, dysk 80 GB, a to wszytko obsługiwane przez system Windows XP, miało spokojnie wystarczyć na kolejne lata.
Zresztą patrząc w zalecenia podane przez Microsoft dla systemu Windows XP mówią same za siebie. (źródło)
Minimalne wymagania sprzętowe dla systemu Windows XP Professional obejmują:
- Procesor Pentium 233 megaherców (MHz) lub szybszy (zalecany procesor 300 MHz)
- Przynajmniej 64 megabajty (MB) pamięci RAM (zalecane 128 MB)
- Przynajmniej 1,5 gigabajta (GB) wolnego miejsca na dysku twardym
- Stacja dysków CD-ROM lub DVD-ROM
- Klawiatura i mysz Microsoft Mouse lub dowolne inne zgodne urządzenie wskazujące
- Karta wideo i monitor o rozdzielczości Super VGA (800 x 600) lub wyższej
- Karta dźwiękowa
- Głośniki lub słuchawki
Niestety po roku czasu szybko się okazało, iż 512 MB to jednak za mało na rosnące potrzeby aplikacji ale także systemu. Samo pojawienie się już kolejnych wersji aktualizacji Service Pack 2 i 3 zwiększało zapotrzebowanie na pamięć RAM. Z mojego punktu widzenia minimalne wymagania dla systemu z wgranymi wszystkimi aktualizacjami wzrosła przynajmniej do 192 MB, z czego zalecane bym uznał 256 MB. Czyli dla aplikacji pozostawało nam 256 MB RAMu! Sami przyznacie, że trochę mało.
Poszukiwanie rozwiązania
Najprostszą rzeczą która mogła by rozwiązać problem było dokupienie dodatkowej pamięci RAM. Z założeniem, że komputer ma posłużyć jeszcze przez dłuższy czas, brałem pod uwagę zakup dodatkowej kości 512 MB. Niestety ceny były zaporowe. Postanowiłem przerzucić próbę rozwiązania problemu z hardware na software. Inaczej mówiąc, zacząłem od systemu operacyjnego. Na pierwszy ogień poszły wszelkie możliwe „optymalizacje Windowsa”. Wyłączyłem zbędne usługi systemowe oraz aplikacje. Po prostu zastosowałem się do ogólnodostępnych wskazówek, które można było znaleźć na tamte czasy w internecie. Wynik był jednak mizerny. Zajętość pamięci RAM wyglądała w prawdzie lepiej, ok 70% wolnej i gotowej do pracy. Radość jednak trwała krótko, wystarczyło odpalić jedną większa aplikację, a wolna pamięć znikała w oczach. Nie było by w tym nic dziwnego. W końcu aplikacja potrzebuje ten pamięci do pracy, to dlaczego by nie mogła jej dostać? Gdyby tylko jeszcze ją oddawała w momencie kiedy nie jest jej już potrzebna.Wtedy jeszcze nie wiedziałem dokładnie jak system zarządza pamięcią, dlaczego tak i jak by można było to zmienić.
Aplikacji do czyszczenia pamięci RAM
Pewnie wielu z was korzystało z niejednego rozwiązania do czyszczenia pamięci. Wszystkie rozwiązania jakie udało mi się przetestować miały jedną zasadniczą wadę. Działały na kilka minut i blokowały komputer w momencie czyszczenia! Zasada działania była banalna. Zajmij maksymalnie największy obszar pamięci operacyjnej po czym zwolnij jej zawartość. W efekcie system widząc tak duże zapotrzebowanie na ram, zrzucał wszystko do pliku wymiany. Wizualnie rezultat został osiągnięty, pamięć była wolna. Działa? Działa! Szkoda że przez kilka minut. Przy tym procesor i dysk „spocone” niemiłosiernie. W końcu trzeba przeliczyć, które obszary pamięci zapisać na dysku w pliku wymiany. Wykonać zapis, a nie daj boże jak jakaś aplikacja akurat zażądała swoich danych, znajdujących się w pliku wymiany. Ogólnie mówiąc koszmar.
Inne spojrzenie na sprawę
Przeszukując internet w poszukiwaniu rozwiązania, natrafiłem na artykuł Jacka Światowiaka, na stronach TechNetu. Postanowiłem wgłębić się w sam sposób zarządzania pamięcią w systemach Windows. I tam poszukać rozwiązania mojego problemu. Po ok tygodniu studiowania, dokumentacji oraz różnych publikacji w internecie. Postanowiłem odpalić edytor i napisać testowo pierwsza bibliotekę w C, która wyszuka nieużywanych obszarów pamięci. Po kilku godzinach zabawy, mogłem ogłosić sukces. Nie obyło się oczywiście bez kilku niebieskich ekranów. 🙂 Kolejnym krokiem było zmusić system do oddania nieużywanej pamięci. Tu przyszło z pomocą samo API systemu Windows. Oczywiście nie obyło się bez własnych rozwiązań. I tak po kilku dniach testów postanowiłem dorobić proste logowanie do pliku i uruchomić testowo w tle.
Testy w praktyce
Według mnie najlepszy test to środowisko produkcyjne. Tak też się stało w moim przypadku. Aplikacja do optymalizacji pamięci chodziła sobie w tle. Komputera używałem jak zwykle do pracy i rozrywki. Zauważalne było przyśpieszenie aplikacji które wcześniej miały problemy. Uznałem, że dobrze by było dać aplikację do przetestowania kilku innym osobą. Tak narodził się pomysł stworzenia prostego interfejsu graficznego aplikacji. Wybór padł na Delphi 7. Sam mechanizm napisany w C i umieszczony w pliku DLL, który został podpięty do środowiska graficznego „wyklikanego” w Delphi. Pierwsza myśl: „to nie może działać”. Ale cóż podeślemy kilku testerom, niem sami się wypowiedzą. Muszę przyznać że spotkałem się z ciekawym podejściem kolegi, który jak usłyszał, że próbuję go uraczyć „kolejnym optymalizatorem pamięci”. Rzucił prostym, „nie chce kolejnego dziadostwa które muli kompa, a i tak nie działa”. Mimo wszystko po dłuższej rozmowie uległ i postanowił zainstalować RAM Kontrolera 1.0. (Pozdrowienia dla Pawła 🙂 ). Poprosiłem wszystkich testujących o wykonywanie normalnych czynności, jakie wykonują na co dzień, na swoich komputerach. Po 2-3 dniach postanowiłem wstępnie wypytać jakie wrażenia z używania mojego „wynalazku”. Wyniki były pozytywne. Testerzy widząc rezultaty postanowili pomęczyć swoje komputery. A to otworzyć najwięcej aplikacji, a to pobić swój rekord w ilości zakładek w przeglądarce. Ogólnie rzecz biorąca, dali wycisk aplikacji.
Ewolucja
Sama aplikacja rozwijała się powoli. Nie było potrzeby nic modyfikować, a grono użytkowników wynosiło raptem 25-30 osób. Jedną z większych modyfikacji jaka powstała było wydanie wersji 1.1, został zmieniony algorytm aplikacji. Problem powstał z pojawieniem się komputerów z większa ilością pamięci RAM (ponad 1 GB). Algorytm wyszukiwania był zbyt wolny i zasobożerny. Było to też pierwsze podejście do wielowątkowości aplikacji. Jeden wątek analizował pamięć, a drugi zajmował się jej odzyskiwaniem. Z punktu widzenia użytkownika zmieniły się też nieznacznie możliwości interfejsu. Aplikacja pokazywała aktualną ilość wolnej pamięci. Około roku 2010 aplikacja przeszła konkretną przebudowę algorytmu. Było to związane z systemem Windows Vista. Niestety ale nowe rozwiązania Microsoftu trochę pokrzyżowały założenia samej aplikacji. System operacyjny starał pchać do pamięci RAM wszystko co mogło być za chwile użyte przez użytkownika. I tak po uruchomieniu komputera, mieliśmy w pamięci system, z aplikacjami i stertą plików różnego typu oraz bibliotek DLL. Ciekawostką było to ze przez pewien czas Windows potrafił sam siebie „zabijać” ładując np. wszystkie pliki mp3 bo najczęściej używaną aplikacją był WinAmp. Taka pamięć jest specjalnie oznaczana przez system, jako gotowa do użytku ale jednak posiadająca dane. RAM Kontroler uznawał ową przestrzeń za używaną i zostawiał w spokoju. Poprawki wprowadzone w wersji 1.2 pozwoliły ponownie używać aplikacji w systemie Windows Vista. Jednocześnie aplikacja stałą się na tyle sławna, że pojawiła się w popularnych serwisach do pobierania plików. Komputer Świat także poświęcił 5 minut dla RAM Kontrolera i załączył program na swojej płycie DVD.
Nadchodzi .NET
Wraz z wyjściem aplikacji w wersji 1.3 postanowiłem napisać wszystko od zera. I całe środowisko programistyczne oprzeć na C# zgodnym z .NET 4.0. Wybór wersji 4.0 jest uzasadniony z powodu wsparcia systemu Windows XP. Microsoft nie przewiduje nowszej wersji niż 4.0 na systemach Windows XP. Już pomijam wersje Windows 2000. Dla tego systemu dalej można używać wersji 1.2.
Zmiany pozwoliły na zmianę podejścia do obsługi procesów, pamięci i samego interfejsu użytkownika. Powstała także wersja 1.3.1 oznaczona dalej jako beta. Nowością jest monitorowanie użycia procesora i dysku. Dodano także mechanizmy wykrywania instalacji. Zdarzały się przypadki, że RAM Kontroler zabierał całą pamięć programowi instalacyjnemu. Co wydłużało czas instalacji, nawet i pięciokrotnie. Po wprowadzeniu nowych mechanizmów problem ustąpił. Nowe funkcje monitorowania, mają za zadanie zapobiegać z automatu takim przypadkom. Jeśli aplikacja pracuje i znacząco używa procesora to dlaczego mamy jej zabierać pamięć? Możliwe że za chwilkę będzie znowu jej potrzebować.
Co dalej?
Patrząc z perspektywy czasu, muszę przyznać że jestem zadowolony z RAM Kontrolera. Trochę mniej z postępu prac nad aplikacją. Zawsze było i jest coś ważniejszego. Mimo to sama aplikacja zdołała sobie wyrobić dobra i złą opinię wśród użytkowników. Na chwile obecną nie planuje wydać nowej wersji aplikacji. Jeśli czas pozwoli, chciałbym wersje 1.3.1 doprowadzić do stanu finalnego i pozbyć się statusu beta. Wyprowadzić wszystkie zgłoszone uwagi i błędy, oraz uporządkować miejsce z którego można pobrać aplikacje. Obecnie jest to dość utrudnione.
Pragnę podziękować wszystkim za te dobre słowa, ale także za wszystkie krytyczne uwagi pod względem aplikacji. Dziękuje 🙂
Na koniec…
Tak sobie przez te lata zbierałem opinie o mojej aplikacji i doszedłem do pewnego wniosku. Świat użytkowników Windowsa dzieli się na kilka grup jeśli chodzi o RAM w systemie. Jedni uważają, że duża ilość zajętej pamięci to zło i należy mieć wolne przynajmniej 60%. Inni zaś uważają, że po to jest pamięć żeby była zajęta. Ja zaliczam się do tej drugiej grupy. Jest RAM, to ma być używany, ale najważniejsze żeby był mądrze przydzielany. 🙂