Хакер Алекс Хастингс из компании Aptiverse.com провёл небольшое расследование, насколько снижается производительность браузера Google Chrome через несколько недель после установки программы. Для замеров он набрал 20 добровольцев и установил на их компьютеры программу мониторинга. На диаграмме показано увеличение времени задержки при навигации по веб-страницам от 10 миллисекунд в первый день использования до примерно 90 миллисекунд через 30 дней использования. На диаграмме показан также рост объёма кэша за тот же промежуток времени (красная линия).

По каким-то причинам браузер Chrome работает с кэшем и историей сёрфинга совершенно не так, как остальные браузеры. Все остальные хранят эту информацию максимум несколько месяцев, а потом стирают для экономии дискового места и повышения производительности системы и браузера, в частности. А вот браузер Chrome хранит все данные бесконечно. В результате, временные файлы, кэш и история сёрфинга Chrome вместе с индексными файлами истории за каждый месяц и дистрибутивом каждой новой версии браузера (да, Chrome не удаляет ни одной из предыдущих версий дистрибутива после автоматического обновления на новую версию) — все эти файлы могут занимать несколько гигабайт на жёстком диске.

Но самая главная проблема не в исчезновении дискового пространства, а в деградации производительности из-за увеличения размера кэша, разрастания истории поиска и некорректной реализации карты хэшей в infinite_cache.cc.

Для сравнения, вот график увеличения размера кэша и изменения задержки при сёрфинге в браузере Firefox, который после первоначальной инсталляции показывал результат слегка худший, чем в Google Chrome.

Алекс Хастингс также отмечает, что движок WebKit отличается специфической культурой кода с использованием кратких, маленьких методов. Например, в функциях, отвечающих за рендеринг типичной веб-страницы, движок WebKit насчитывает в среднем 2,1 выражения C++ на функцию, тогда как у Firefox этот показатель составляет 6,3, а у Internet Explorer он равняется 7,1. Подобный подход к программированию ведёт, однако, к чрезмерному количеству запросов vtable, из-за чего страдает производительность рендеринга реальных веб-страниц. На диаграмме показан средневзвешенный оверхед рендеринга наиболее популярных веб-страниц из-за рекурсивных запросов к коду (в процентах).

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии