r   e   k   l   a   m   a
r   e   k   l   a   m   a

Google Chrome w rzeczywistości wcale nie tak wydajne jak w benchmarkach?

Strona główna Aktualności

Gdy Chrome zaczęło wychodzić ze swego niemowlęctwa, stając się w pewnym momencie najszybciej przejmującą przeglądarką w historii, stało się tak nie tylko dzięki marketingowym staraniom Google'a. Szybkość silnika skryptowego V8, jakość renderowania stron w Webkicie, minimalny, wygodny interfejs użytkownika, łatwość instalacji rozszerzeń – to wszystko sprawiło, że zarówno użytkownicy jak i deweloperzy polubili Chrome'a.

Kolejne wersje google'owej przeglądarki biły kolejne rekordy wydajności w rozmaitych benchmarkach, kolejne artykuły porównujące browsery przyznawały Chrome palmę pierwszeństwa, dając innym producentom przeglądarek nieuchwytny cel w wyścigu, w którym liczyły się milisekundy, tymczasem coraz więcej użytkowników zaczęło odczuwać, że Chrome zwalnia, traci gdzieś swoją zwinność.

Gdy benchmarki rozmijają się z wrażeniami użytkowników, oznaczać to może tylko jedno – benchmarki nie mają większego znaczenia. Syntetyczne testy mogą co najwyżej sprawdzić sprawność poszczególnych komponentów przeglądarki, ale nie zmierzą realnego doświadczenia. Czy takie doświadczenia można jakoś zmierzyć i na tej podstawie ustalić, na co choruje Google Chrome?

Zadanie takie postawili sobie programiści z Aptiverse. Pracując nad projektem mającym zapewnić doświadczenia w czasie rzeczywistym natrafili na problemy z wydajnością przeglądarki, dające się odczuć tylko w Google Chrome. Gdy wyeliminowali możliwość błędu po swojej stronie, pozostało im się przyjrzeć temu, co robi Chrome z bliska. Okazało się, że problemy Chrome'a sięgają bardzo głęboko – do samej architektury przeglądarki. Co gorsze, wyglądają na wyniki świadomie podjętych przez Google'a decyzji biznesowych.

Po pierwsze, model obsługi bufora i historii w Chrome okazał się bardzo niedogodny dla użytkownika. Zdecydowana większość przeglądarek nakłada ograniczenia na rozmiar danych przechowywanych w buforze i liczbę dni historii przeglądania. Dane z serwisów, które nie były dłuższy czas odwiedzane, znikają z czasem z dysku. Jednak w przeglądarce Google'a jest inaczej. Dane przechowywane są w buforze w nieskończoność, a to oznacza, że z czasem zapytania do bufora są coraz mniej wydajne. Początkowo opóźnienia między aktywacją interfejsu użytkownika a rozpoczęciem ruchu sieciowego w Chrome są minimalne, ale wystarczyło 30 dni, by stały się dwukrotnie większe niż w początkowo nieco wolniejszym Firefoksie, utrzymującym rozsądne ograniczenia rozmiaru bufora.

Z czasem więc każdy nowy zasób pobierany przez Chrome pogarsza wydajność przeglądarki. Najbardziej jest to odczuwalne w wypadku aplikacji webowych korzystających z metody pushState() do modyfikowania zawartości wpisów w historii przeglądarki.

Po drugie, okazuje się, że WebKit, ze względu na przyjętą przez jego autorów metodykę programowania (stosowanie krótkich, nie potrzebujących dodatkowej dokumentacji metod), nie jest wcale tak wydajny, jak twierdzi teraz np. Opera Software. Jak wyjaśnia Alex Hastings, dyrektor techniczny Aptiverse, zakrojone na szeroką skalę wykorzystanie dynamicznego dziedziczenia klas prowadzi do gorszej optymalizacji krótkich funkcji przez kompilator oraz powoduje spory narzut na wydajność, ze względu na ciągłe przenoszenie parametrów funkcji na stos i przełączanie kontroli między fragmentami kodu. Pomiary rozmiaru tego narzutu pokazały, że np. uruchomienie Facebooka generuje w Chrome narzut o kilkanaście punktów procentowych większy niż w IE czy Firefoksie. Co ciekawe, serwis Google+ wydaje się być wyraźnie zoptymalizowany pod Chrome'a – tam narzut dla Chrome'a jest o kilka punktów procentowych niższy, niż dla innych przeglądarek. Google'owa przeglądarka „lubi” po prostu niektóre typy layoutów, szczególnie mocno zagnieżdżony DOM.

Po trzecie, słynna izolacja procesów w Chrome, mająca zapewnić większą stabilność i bezpieczeństwo aplikacji webowych, obciążona jest według dyrektora technicznego Aptiverse wykorzystaniem przestarzałych koncepcji – realizowane są przez mający małą przepustowość podsystem IPC, któremu towarzyszą zasobożerne operacje systemu operacyjnego. Próby synchronizacji stanów pomiędzy dwoma procesami Chrome'a okazują się przez to być bardzo kosztowne: mierząc opóźnienia synchronicznych prób pisania między dokumentami i otwartymi oknami przeglądarki, okazało się, że w Chrome są one zupełnie nieprzewidywalne, z bardzo dużymi skokami amplitudy. Dla porównania Firefox zapewnia znacznie bardziej przewidywalny i regularny poziom opóźnień.

Czy Google spróbuje naprawić Chrome'a? Trudno powiedzieć – odkrycia Aptiverse nie wyglądają na zwykłe usterki, to raczej przykład tego, co określa się faulty by design. W tej sytuacji decyzja Opery o sięgnięciu po bazę kodu Chromium może okazać się strzałem w stopę: wraz ze wszystkimi zaletami silników Google'a, będzie musiała przejąć ich wady, szczególnie boleśnie odczuwalne na urządzeniach mobilnych. Jeśli ktoś nie wierzy, jak bardzo są to wady odczuwalne, niech porówna sobie wydajność Chrome dla Androida z wydajnością Opery Mobile, przeglądarki wciąż na silniku Presto.

r   e   k   l   a   m   a
© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.