Я как-то писал про производительность с gcc vs clang. Попугаеметры (https://web.basemark.com) и личные ощущения показывают, что, когда Chromium собирается с use_lld=true, производительность проседает более чем на 10%. На x86_64 сборочная система ставит lld даже если задано, например, use_gold=true. Вот этот патч https://abf.io/mikhailnov/chromium-browser-stable/blob/rosa2016.1/ROSA-allow-Gold-on-Linux.patch убирает это, но тогда сборка падает на более поздних этапах. В итоге наилучшая производительность при use_gold=false use_lld=false, тогда используется линковщик GNU FD, он медленнее gold и lld, но дает наилучшую производительность. Например, в Ubuntu Chromium собирается с ним и работает чуть быстрее самого Google Chrome, который собирается с use_lld + allow_posix_lto.
Написал немного запутанно, в общем, я предлагаю поставить: use_gold=false use_lld=false на x86_64, на i586 можно так: use_gold=true Указанный патч не нужен.
В ближайшее время я не планирую менять опции сборки. Бага пусть весит на память.
Все-таки не покидает устойчивое впечатление, что Хромиум под Альтом микрофризит под нагрузкой, особенно в тяжелых веб-приложениях.
Сопровождающий в комментарии 2 отказался менять линковщик, а апстрим с тех пор сделал предложенную конфигурацию невозможной. chromium 152.0.7977.82-alt1 собирается с use_lld=true (chromium.spec:475) и ThinLTO на 64-битных архитектурах (spec:476-478: use_thin_lto=true thin_lto_enable_optimizations=true). В апстримной системе сборки build/config/compiler/compiler.gni:33 — "use_lld = is_clang && current_os != zos" (lld по умолчанию), build/config/compiler/BUILD.gn:762 — assert(use_lld, "LTO is only supported with lld"), а переменной use_gold больше нет вовсе. Отказ от lld означал бы отказ от LTO, что перечёркивает замер производительности из 2018 года. Debian тоже собирает с use_thin_lto=true, то есть lld.
