Немного о Google Chrome

У всех свои вкусы - кто-то предпочитает Opera, кто-то поклоняется FF. Особо невезучие используют IE) Мой выбор пал на Chrome. Но не пугайтесь, целью данного текста не является описание достоинств этого браузера, а представление результатов исследования его производительности.

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

Итак, среда и инструменты исследования. Версия Google Chrome 12.0.742.112, ОС - Windows 7 x86 на двухъядерном Intel Atom. В качестве скальпеля я использовал две утилиты из пакета sysinternals - ProcessExplorer и ProcessMonitor. К тому же я подключил профилировщик Code Analyst, а также скачал сорцы Chromium, который является основой Google Chrome.

Но для начала можно вполне обойтись самим Chrome) В нем есть страница с просто убийственным названием about:about, которая содержит список скрытых страниц настроек браузера. Например, на странице about:memory можно увидеть, сколько памяти потребляет Chrome и его отдельные элементы, about:gpu-intervals выдает информацию о графике, about:conflict покажет все dll, которые уже загружены, или еще будут подключены. About:dns расскажет все о dns серверах, которыми пользуется браузер, а about:plugin - о плагинах. Здесь стоит напомнить, что все страницы хрома выделяются в отдельный поток - это достаточно интересная фишка, которая позволяет убить повисшую вкладку без влияния на другие. Но заметим - все расширения хрома также представляют собой отдельную страницу в браузере. Видимо, Chrome должен порождать большое количество потоков? Именно! Взглянем на него через призму ProcExp'а и увидим n-ое количество процессов (у меня было 15), каждый из которых включает примерно 5 потоков. Внушительное количество, на мой взгляд)

CodeAnalyst продолжит эту тему. Если мы взглянем на результаты профилирования, то увидим, что больше всего времени уходит на ntkrnlpa.exe и chrome.dll

Вопрос, что именно делают эти модули? Ответ)

Функция KiDispatchInterrupt предназначена для переключения контекста потока, который выполняется на процессоре. Очевидно, что чрезмерное количество потоков, которые порождает браузер, бьет (и очень больно) по производительности - 85% всего времени уходит на переключение!

Chrome же увлеченно занимается вызовом функции с говорящим названием RelaunchChromeBrowserWithNewCommandLineIfNeeded) По названию примерно понятно, для чего нужна эта функция, но все же вот код, взятый из chromium

//for win
bool RelaunchChromeBrowser(const CommandLine& command_line) {
  scoped_ptr env(base::Environment::Create());
  env->UnSetVar(chrome::kChromeVersionEnvVar);
  return base::LaunchApp(
      command_line.command_line_string(), false, false, NULL);
}

//for mac
bool RelaunchChromeBrowser(const CommandLine& command_line) {
  return mac_relauncher::RelaunchApp(command_line.argv());
}

//for linux
bool RelaunchChromeBrowser(const CommandLine& command_line) {
  return base::LaunchApp(command_line, false, false, NULL);
}

Т.е. эта функция перезапускает браузер с новыми аргументами - это нужно для расширений, которые запускаются с помощью указания различных аргументов (--type=extension).

С зависимостью производительности от количества потоков разобрались, пару слов об истории. Казалось бы сохранение истории должно также влиять на скорость работы браузера, но, видимо, это не про Chrome. По крайней мере, фильтр по History указывает, что перехваченных вызовов, которые можно отнести к работе с историей, всего 1% от общего количества.

Итак, краткий обзор Google Chrome закончен. Не стоит рассматривать все выше перечисленное, как недостатки - это всего лишь следствия архитектуры приложения, которые в разных случаях могут стать и положительными и отрицательными моментами. (к слову, в данный момент использую именно Chrome))