Wieloprocesowość
Od czasu pojawienia się Chrome, temat korzystania z wielu procesów do wyświetlania stron w przeglądarce stał się jednym z ważniejszych przy porównywaniu przeglądarek.
Co więcej, wbrew uwagom samych autorów, powszechnie zaczęto uznawać to jako tzw. “feature” – funkcję, której posiadanie jest bezwględnie objawem przewagi danej przeglądarki nad inną.
Czarne strony
Tymczasem Sam Allen opublikował wynik swojego mini-badania w którym przetestował popularne przeglądarki w zakresie zużycia pamięci. Oto wykres:
Sam przetestował Operę, Firefoksa, Safari i Chrome podczas wczytywania 150 najpopularniejszych stron z rankingu Alexa.com. Opublikował też wyniki w postaci tabeli najwyższego i najniższego zużycia pamięci przez różne przeglądarki.
Sam wykres jest na pewno ciekawy, ale jeszcze ciekawsze są jego implikacje, które potwierdzają pierwsze komentarze jakie pojawiły się w społeczności pracującej nad Gecko po wydaniu Chrome.
Dlaczego tak się dzieje? Wykorzystanie wielu procesów oznacza, że 10 kart z otworzonym google.com będzie dziesięć razy ładować absolutnie wszystko konieczne do wyświetlenia tej strony. To zaś oznacza znaczące koszty w wykorzystaniu pamięci. W “tradycyjnym” modelu, pamięć jest współdzielona i obrazki, struktury danych oraz bloki używane do rysowania układu strony mogą być współdzielone. Nawet obiekty używane do wyrenderowania strony, mogą zostać utworzone raz i uruchamiane podczas rysowania różnych stron.
Tymczasem w przypadku modelu w którym każda strona (czy karta) ma swój proces, musi ona praktycznie załadować do pamięci całą przeglądarkę – a przynajmniej cały kod potrzebny do obługi jednej strony. To kosztuje i to wcale nie mało.
Białe strony
Czy to oznacza, że programiści Chrome popełnili błąd decydując się na taką zmianę? Nie. Oni po prostu zdecydowali się zapłacić taką cenę, za liczne udogodnienia jakie daje rozdział procesów.
Najważniejszym, i pewnie najbardziej zrozumiałym jest możliwość izolacji procesu na wypadek problemów. Jeśli strona spowoduje poważny błąd, będzie to tylko błąd tej karty, a nie całej przeglądarki. Nie stracimy pisanego od godziny listu i nie będziemy musieli uruchamiać wszystkiego od nowa. To duża wygoda.
Inną sprawą jest rozdzielenie pamięci. Strony można uruchamiać w tzw. “piaskownicach”, gdzie są oddzielone od sektorów pamięci wykorzystywanych przez przeglądarkę. W takiej sytuacji nawet jeśli w przeglądarce znajdzie się błąd bezpieczeństwa, to jego wykorzystanie praktycznie zawsze będzie ograniczone do manipulacji danym procesem, a nie całą przeglądarką czy systemem operacyjnym. To ważne udogodnienie.
Istnieją inne, jak łatwe wykorzystanie wielu procesorów i przeniesienie na system operacyjny zarządzania przydzielaniem procesom cykli procesora, co oznacza, że z łatwością można określić, że przeglądarka ma wyższy priorytet niż, np. filmik na youtube i nie będzie on już “przycinał” jej.
Szukanie balansu
W Mozilli powstał specjalny projekt, który eksperymentuje z wykorzystaniem wieloprocesowości. Pierwsze eksperymenty są już testowane i poniżej prezentuję filmik od Chrisa Blizzarda z demonstracji tej technologii:
Najważniejszym jednak pytaniem jest jak wykorzystać wieloprocesowość, aby zmaksymalizować zyski i zminimalizować koszty. Jednym z pomysłów jest uruchamianie rozszerzeń w osobnych procesach – to zwiększa bezpieczeństwo i pozwala oddzielić stabilność aplikacji od rozszerzenia, ale kosztem pamięci. Innym pomysłem jest wydzielenie procesów na wtyczki, ponieważ w nich często znajdowane są błędy bezpieczeństwa a także one najczęściej zawieszają przeglądarki.
Jeszcze innym jest utrzymywanie silnika renderującego w osobnym procesie a stron w osobnych. Wówczas strona wysyłana by była przez kartę do procesu renderującego, który zwracałby wyrenderowaną. W takim układzie karty są niezależne, jeśli jakaś operacja na jednej spowoduje błąd to nie dotknie on innych, a zużycie pamięci nie powinno ucierpieć, ponieważ kod renderujący byłby współdzielony. Niestety taki układ nie daje tych samych zalet w zakresie stabilności. Jeśli silnik rednerujący wyłoży się na jednej stronie, to padnie cały. Jeśli jednak będzie osobnym procesem, to nie przełoży się to na przeglądarkę…
Generalnie temat do rozważań jest potężny i jest mnóstwo miejsca na eksperymenty. Jeśli ktoś jest zainteresowany pracą zespołu, to zapraszam na serwer irc.mozilla.org, kanał #content.