Блог

В настоящее время я взвешиваю потенциальные плюсы и минусы запуска локальных сборок Chromium.

Я никогда раньше не собирал Chromium из исходного кода, но я понимаю, что это огромный проект, и требования к компиляции большие и отнимают много времени.

Я пробовал эту идею раньше, но по причинам, связанным с производительностью. В конкретных:

• Может ли Chromium извлечь большую выгоду из оптимизации, ориентированной на профиль?
• Может ли сборка Chromium с использованием встроенной оптимизации процессора GCC обеспечить более чем незначительное преимущество в производительности по сравнению с использованием общих двоичных сборок? (В частности, с арками Haswell и Broadwell)
• Есть ли что-нибудь еще, что можно сделать для повышения общей производительности или эффективности памяти при локальной сборке Chromium?

После небольшого исследования я пришел к выводу, что это не будет стоить затраченных усилий.

Я помню, как запускал PGO-сборки Firefox несколько лет назад, и Firefox, похоже, все еще предлагает достойную поддержку для запуска PGO-сборок. Однако в случае с Chromium это выглядит намного сложнее.

Похоже, что у Chromium есть некоторая встроенная поддержка сборок PGO. К сожалению, эта поддержка, похоже, полностью зависит от Windows. Сборки PGO для других операционных систем не поддерживаются, и со всеми уникальными сложностями сборки Chromium, казалось, не стоило пытаться выполнить сборку PGO без этой помощи.

Если кто-нибудь еще знает кого-то, кто успешно пытался это сделать в Linux, мне было бы очень интересно увидеть результаты.

Что касается оптимизации процессора GCC, я понимаю, что предоставляемые здесь преимущества почти всегда незначительны, но, учитывая сложность Chromium, кажется правдоподобным, что он может извлечь из этого больше пользы, чем большинство приложений.

Вероятно, по-прежнему не стоит прилагать усилия только для оптимизации GCC, но причина, по которой я рассматриваю возможность сделать это снова, заключается в том, что я также могу воспользоваться исправлением для включения VA-API: https://aur.archlinux.org/packages/chromium-vaapi /

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

tl; dr

• Могу ли я ожидать какой-либо заметной разницы в производительности при использовании сборки Chromium, скомпилированной локально с оптимизацией собственного процессора?
• Возможен ли PGO с Chromium в Linux, и если да, то каковы наилучшие способы выполнения фактического профилирования?

Черт возьми, я запускаю Gentoo Linux, что означает, что все в моей системе скомпилировано из исходного кода. Я чередовал сборку chromium из исходного кода с пользовательскими cflags и использованием бинарного пакета google-chrome-stable, который также доступен. Я действительно замечаю улучшение производительности при запуске локально скомпилированного chromium по сравнению с предварительно упакованный двоичный файл Google Chrome.

Теперь, является ли это результатом оптимизации компилятора или различий между версиями Google Chrome и Chromium (на данный момент они довольно близки друг к другу — Google Chrome 55.0.2883.87 и Chromium 55.0.2883.75), я не могу сказать. Но улучшения было достаточно, чтобы я вернулся к Chromium и, вероятно, останусь с ним на некоторое время.

Недостатком сборки из исходного кода (особенно если обновление пакетов в вашей ОС означает ее перестройку) является то, что он часто запускается, а его сборка занимает около двух часов на ноутбуке i7 8Gb с SSD. Таким образом, это превращает большинство системных обновлений в долгий и медленный процесс — вот почему я перешел на бинарные сборки год или два назад.