Optymalizacja, czyli jak bardzo komunikatory zjadają Ci systemu zasoby

Wpis powstał sobie z potrzeby wytłumaczenia kliku rzeczy, prawdopodobnie tysiącom ludzi. Ileż to razy pod różnymi komunikatorami widzimy wpisy w rodzaju "a u mnie zabiera tylko 9 Mega ramu", w domyśle "pewnie masz coś nie ta z systemie skoro Tobie zjadło 60!". Problem polega jednak na tym, że takie "porównania" są dokładnie warte tyle co nic. Gdyż, ponieważ, bo: jeden użytkownik ma 10 kont protokołów dodanych, inny ma jedno, trzeci ma 4 ale za to ma włączone awatary albo sprawdzanie pisowni, które często pochłaniają spore ilości pamięci i czasu procesora. A nawet gdyby wszyscy mieli takie same ustawienia, pozostaje problem pod tytułem "komunikatory dostają różne ilości/typ danych". Rozumiemy, że tak się nie da?

Powstała zatem myśl, aby zrobić porównanie tego jak bardzo "zjadliwe" są te programy dla systemu, w miarę identycznych warunkach. Na warsztat wziąłem 5 sztuk testowych: AQQ (2.2.4.50), WTW (0.8.5.2510), Kadu (beta bodaj 11), Miranda (0.9.16) oraz Tlen7 (7.0.0.72). Dlaczego te? Bo są w większości multikomunikatorami, i potrafią spełnić warunek "jedno konto gadu i jedno xmpp". Wszystkie były uruchomione w tym samym czasie i z wyjątkiem tlenu były podłączone do tych samych kont. Tlen z uwagi na jakieś bugi, cały czas twierdził, iż moje hasło jest na xmpp nieprawidłowe... dostał zatem inne konto, na którym zamiast około 100 kontaktów, są całe dwa. To mu jednak nie pomogło. Drugą sprawą jest to, że kadu oraz miranda nie obsługują w pełni multilogowania na gg, konkretnie nie pokazują wysyłanych z innych komunikatorów wiadomości. To dawało im przewagę, gdyż miały do wyświetlenia około połowy wiadomości. Kadu jednak testu nie ukończyło, dwa razy zaliczyło crash. Deweloperzy kadu powiadomieni, zrzut pamięci dostali, twierdzą, że poprawią.

Tak oto prezentowała się nasza piątka. Jeśli zaś chodzi o konfigurację, z kilkoma wyjątkami - została taką jaką przewiduje producent. Wyjątki to: trzeba było dodać/włączyć wtyczki protokołów tak aby uzyskać wspomniane wcześniej dwa konta. Oraz opcje okna wiadomości we wszystkich przypadkach zostały ustawiona na "otwórz okno przy nowej wiadomości".

Wyjątkiem jest tutaj miranda, która nie została użyta w domyślnej konfiguracji. Miranda "wygrałaby" w domyślnej konfiguracji w cuglach (z resztą i tak prowadzi). Miała by też znikomą funkcjonalność. To też (podziękowania dla użytkownika Mirandy zwanego AL|EN) została sprowadzona do mniej więcej funkcjonalnego wspólnego mianownika reszty (co tez właśnie AL|EN sugerował). Można byjeszcze przeprowadzić test z rodzaju "jak się zachowają te programy w "najminimalistyczniejszej konfiguracji", tu bym do współpracy najchętniej zaprosił "community" siedzące wokoło tychże programów, gdyż najlepiej wiedzą jak dokonać optymalizacji swoich pupilków. Tak czy inaczej, na razie bawimy się z ustawieniami domyślnymi.

Jeszcze mała notka, do użytkowników aqq, z niewiadomego powodu, nie chciało mi ono pokazywać reklam, to też... miało jakby fory. Idę o zakład, że jakby te reklamy pokazywało, to obciążeni CPU i pamięci wzrosłoby dramatycznie.

Powyżej widzimy stan liczników kilka minut po uruchomieniu wszystkiego. Przez około 16h wszystkie programy nie robiły nic poza "byciem" i wyświetlaniem wiadomości. Ani jeden nie miał interakcji z użytkownikiem. Wiadomości na xmpp były głownie generowane przez bot blipa, wiadomości na gg to moje rozmowy z paroma znajomymi w podanym wyżej czasie (spoza środowiska testowego, inny komputer). Uwaga mała, takie testy nie są "odtwarzalne", tj nie da się powtórzyć takiego testu dwa razy i uzyskać identycznych wyników. Proporcje miedzy uzyskanymi wynikami będą w miarę identyczne, jednak same wyniki prawie zawsze będą inne. Pokazuje to przykład aqq, który w drugim przebiegu (tak, test był robiony kilka razy) osiągnął wynik 8 minut CPU, a trzecim około 6 minut. Jednak dystans do pozostałych programów utrzymywał się na podobnym poziomie. Po pewnym czasie wyniki ukształtowały się tak:

Wnioski? Na początek: AQQ oszukuje z obciążeniem pamięci RAM. Jego autor jest prawdopodobnie świadomy, że większość użytkowników nie dość, że nie wie co oznaczają poszczególne kolumny w managerze zadań, to jeszcze nie zmienia ich domyślnej konfiguracji. Co więc widzą? Widzą to ile pamięci zjedzonej przez aplikację aktualnie znajduje się w pamięci RAM, tej fizycznej. AQQ tym czasem zmusza system aby większość jego pamięci została przeniesiona do pliku wymiany. W tym momencie wydaje się, że to fajne. Nie. Nie, dlatego że kiedy zapasy wolnej pamięci są spore, nie ma sensu przenosić danych do swapa, bo jak będą potrzebne to będą musiały zostać ponownie wczytane - to zajmuje czas (i procesora i po prostu zmniejsza czas reakcji aplikacji). Poza tym aqq nie sprawdza które dane mogą być przeniesione do pliku wymiany, bo są rzadko potrzebne, tylko przenosi wszystko jak leci. A w wypadku kiedy pamięci fizycznej jest mało system i ta sam przeniesie to co uzna za stosowne poza pamięć fizyczną. Innymi słowy, aqq samo sobie tym marketingowym zabiegiem szkodzi, gdyż poza tym co już wspomniałem, drastycznie podnosi sobie jeden z kluczowych wskaźników służących do oceny wydajnosci, "page faults". Page faults w wypadku aqq wynosi po 16h pracy ponad 6 milionów, konkurencyjny (pod względem obciążenia pamieci) Tlen7 ma ten wskaźnik na poziomie 0,5 miliona. Ale co to jest? Błędy stron, są to momenty, kiedy aplikacja chce doczytać lub zapisać do obszaru, którego nie ma w pamięci fizycznej, i musi być do niej "ściągnięty z dysku". Jeśli kogoś ten temat bardziej interesuje może sobie przeczytać wpis na wiki o tym temacie. Ja tylko powiem, że jeśli ten wskaźnik jest wysoki (w funkcji zajętej pamięci) = źle.

To, że aqq oszukuje widać właśnie z licznika pf, który jest bardzo wysoki jak na takie użycie pamięci. Jest jednak alternatywne do przedstawionego wytłumaczenie takiego poziomu pf, "partacki kod/algorytmy". Nie wiem które lepsze.

Z drugiej strony jest miranda, która bardzo ładnie sobie radzi z praktycznie wszystkim (pomijając fakt, że miała fory). Generalnie komunikatory podzieliły się na dwie grupy, tych ociężałych jak AQQ oraz Tlen v7 i tych raczej lekkich jak Miranda i WTW. Jest jeszcze Kadu, które niestety nie było w stanie (trzy razy) dożyć do rana.

I nie twierdzę bynajmniej, że tlen czy aqq zarżną Wam system. Nie zarżną (póki nie mają reklam), będą działały względnie dobrze, różnicę można będzie jednak zauważyć kiedy wasz system jest pod dużym obciążeniem lub kiedy jest po prostu słaby.

Można jednak pokusić się o takie porównanie: jeśli dany komunikator byłby jedynym procesem obciążającym CPU, i na tlenie 7 teoretyczny laptop działałby godzinę, to na wtw lub mirandzie działałby jakieś 6 razy dłużej.

Na koniec, nikogo nie przekonuję do zmiany komunikatora. Jestem też raczej pewien, ze stosując podobne porównanie (na oczywiście podobnym sprzęcie) dowolny użytkownik chcący odtworzyć test osiągnie podobne proporcje. Z resztą, jeśli czegoś używasz i jesteś z tego zadowolony, po co zmieniać na inny? Mam tylko drobną nadzieję, że kiedyś w odległej przyszłości, autorzy tlenu i aqq wezmą sobie do serca chociaż trochę słówko "optymalizacja", bo to że mój system ma ileś tam GB RAM wcale nie znaczy, że inni mają tak samo, i że to ze komputery są mocne jest wymówką do pisania nieoptymalnego kodu, co szczególnie w wypadku gier i małych programu mających długo działać w tle, mnie strasznie irytuje. Ale może tylko mnie.

Jest jeszcze jedna, nie jakoś szczególnie ważna, ale może czasem przydatna rzecz o której można wspomnieć. DEP i ASLR, oba mechanizmy zabezpieczeń powstały po to aby utrudnić życie tym,którzy bugi w komunikatorach chcieli by do czegoś wykorzystać. Ze wspomnianych komunikatorów, używa ich tylko wtw. Chociaż w praktyce nie wymagają zbytniego poświęcenia ze strony programistów. W większości przypadków wystarczy przestawić jedną opcję w kompilatorze. Choć oba mechanizmy to tylko "ubezpieczenie".

Jeśli macie jakieś uwagi, od tego są komentarze. Co jakiś czas planuję sobie to zestawienie powtarzać, więc s szanse, że sensowne sugestie się przydadzą. Ah i jakby ktoś nie wiedział, ja odpowiadam za kod wtw.

Mały edit

System to Windows 7 x86 z zainstalowanym IE9. Wszystkie komunikatory do pokazywania rozmowy używają silnika przeglądarki: AQQ, WTW, Miranda - Trident (IE), Tlen oraz Kadu - Webkit.

Kolejny mały edit

Kadu, jak słusznie zaobserwowano jest na Windows bardzo nieoficjalnie. To też potraktujmy go jako ciekawostkę, która być może zostanie zastąpiona pidginem.