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

Gdy Chrome zaczęło wychodzić ze swego niemowlęctwa, stającsię w pewnym momencie najszybciej przejmującą przeglądarkąw historii, stało się tak nie tylko dzięki marketingowymstaraniom Google'a. Szybkość silnika skryptowego V8,jakość renderowania stron w Webkicie, minimalny, wygodnyinterfejs użytkownika, łatwość instalacji rozszerzeń – towszystko sprawiło, że zarówno użytkownicy jak i deweloperzypolubili Chrome'a.Kolejne wersje google'owej przeglądarki biły kolejne rekordywydajności w rozmaitych benchmarkach, kolejne artykuły porównującebrowsery przyznawały Chrome palmę pierwszeństwa, dając innymproducentom przeglądarek nieuchwytny cel w wyścigu, w którymliczyły się milisekundy, tymczasem coraz więcej użytkownikówzaczęł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ększegoznaczenia. Syntetyczne testy mogą co najwyżej sprawdzićsprawność poszczególnych komponentów przeglądarki, ale niezmierzą realnego doświadczenia. Czy takie doświadczenia możnajakoś zmierzyć i na tej podstawie ustalić, na co chorujeGoogle Chrome?Zadanie takie postawilisobie programiści z Aptiverse. Pracując nad projektem mającymzapewnić doświadczenia w czasie rzeczywistym natrafilina problemy z wydajnością przeglądarki, dające się odczuć tylkow Google Chrome. Gdy wyeliminowali możliwość błędu poswojej stronie, pozostało im się przyjrzeć temu, co robiChrome 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 decyzjibiznesowych.[img=chrome2]Po pierwsze, model obsługibufora i historii w Chrome okazał się bardzo niedogodny dlaużytkownika. Zdecydowana większość przeglądarek nakładaograniczenia na rozmiar danych przechowywanych w buforze i liczbędni historii przeglądania. Dane z serwisów, które nie byłydłuższy czas odwiedzane, znikają z czasem z dysku. Jednak wprzeglądarce Google'a jest inaczej. Dane przechowywane są w buforzew nieskończoność, a to oznacza, że z czasem zapytania do buforasą coraz mniej wydajne. Początkowo opóźnienia międzyaktywacją interfejsu użytkownika a rozpoczęciem ruchusieciowego w Chrome są minimalne, ale wystarczyło 30 dni, by stałysię dwukrotnie większe niż w początkowo nieco wolniejszymFirefoksie, utrzymującym rozsądne ograniczenia rozmiaru bufora. Z czasem więc każdy nowy zasóbpobierany przez Chrome pogarsza wydajność przeglądarki.Najbardziej jest to odczuwalne w wypadku aplikacji webowychkorzystających z metody pushState()do modyfikowania zawartości wpisów w historii przeglądarki.Po drugie, okazuje się, żeWebKit, ze względu na przyjętą przez jego autorów metodykęprogramowania (stosowanie krótkich, nie potrzebujących dodatkowejdokumentacji metod), nie jest wcale tak wydajny, jak twierdzi teraznp. Opera Software. Jak wyjaśnia Alex Hastings, dyrektor technicznyAptiverse, zakrojone na szeroką skalę wykorzystanie dynamicznegodziedziczenia klas prowadzi do gorszej optymalizacji krótkichfunkcji przez kompilator oraz powoduje spory narzut na wydajność,ze względu na ciągłe przenoszenie parametrów funkcji na stos iprzełączanie kontroli między fragmentami kodu. Pomiary rozmiarutego narzutu pokazały, że np. uruchomienie Facebooka generuje wChrome narzut o kilkanaście punktów procentowych większy niż w IEczy Firefoksie. Co ciekawe, serwis Google+ wydaje się byćwyraźnie zoptymalizowany pod Chrome'a – tam narzut dla Chrome'ajest o kilka punktów procentowych niższy, niż dla innychprzeglądarek. Google'owa przeglądarka „lubi” po prostu niektóretypy layoutów, szczególnie mocno zagnieżdżony DOM.Po trzecie, słynna izolacjaprocesów w Chrome, mająca zapewnić większą stabilność ibezpieczeństwo aplikacji webowych, obciążona jest wedługdyrektora technicznego Aptiverse wykorzystaniem przestarzałychkoncepcji – realizowane są przez mający małą przepustowośćpodsystem IPC, któremu towarzyszą zasobożerne operacje systemuoperacyjnego. Próby synchronizacji stanów pomiędzy dwoma procesamiChrome'a okazują się przez to być bardzo kosztowne: mierzącopóźnienia synchronicznych prób pisania między dokumentami iotwartymi oknami przeglądarki, okazało się, że w Chrome są onezupełnie nieprzewidywalne, z bardzo dużymi skokami amplitudy. Dlaporównania Firefox zapewnia znacznie bardziej przewidywalny iregularny 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ę faultyby design. W tej sytuacjidecyzja Opery o sięgnięciu po bazę kodu Chromium może okazaćsię strzałem w stopę: wraz ze wszystkimi zaletami silnikówGoogle'a, będzie musiała przejąć ich wady, szczególnie boleśnieodczuwalne na urządzeniach mobilnych. Jeśli ktoś nie wierzy, jakbardzo są to wady odczuwalne, niech porówna sobie wydajność Chromedla Androida z wydajnością Opery Mobile, przeglądarki wciąż nasilniku Presto.