Comments 19
Немного чисел результатов оптимизации:
В сентябре 2025 влияние оптимизации сокращения полных путей до имени в Яндекс Браузере было такое:
При одновременном использовании cокращённых LOG и FROM_HERE скорость старта улучшается на 2% (146 мс) по результатам внутреннего теста производительности.
Замечу, что результат не статичен и меняется с течением времени от развития кодовой базы.
Также эффект от оптимизации может отличаться от проекта к проекту.
Оптимизация ещё интересна тем, что теперь её стало проще реализовать для получения выигрыша в других проектах.
Как-то тема производительности вообще не раскрыта, хотя в заголовке упомянута.
Да и тема размера тоже, то что dll уменьшится от такого было и так нетрудно догадаться, интереснее было бы конкретные показатели увидеть.
А время сборки как-то изменилось?
интереснее было бы конкретные показатели увидеть.
https://habr.com/ru/companies/yandex/articles/952410/#comment_28936056.
А время сборки как-то изменилось?
По этому вопросу у нас нет данных, этот показатель не отслеживается.
Однако изменений во времени сборки лично я не заметил.
«За изобретение ставлю 5, а по предмету неуд»
Столько расписывать, как изменение значительно уменьшит размер DLL, но в итогах не написать на сколько…
Ещё правильнее было бы вынести инфо для отладки в отдельный файл, как это сделано в линуксах во всяких dbgsym/debuginfo, но это, конечно же, слишком сложно для таких небольших фирм, как гугл и яндекс.
Это же не отладочные символы, а строковые литеры, которые пишутся в лог. Их так не вынести.
Почему не вынести? Строки для локализации на 100500 языков же как-то выносят? А ещё можно добавить в билд проход препроцессора, который выпишет все логовые строки в отдельную длл.
Строки для локализации на 100500 языков же как-то выносят
Их все равно придется грузить в память. Смысл их выносить в отдельный файл? Символы выносят как раз потому что они нужны только отладчику.
Строки для локализации выносят, чтобы заменять их без перекомпиляции, а не для сокращения размера файла.
Дллку тоже приедется грузить в память.
Думаю, вы не обладаете достаточным пониманием и контекстом, чтобы утверждать, как "лучше". Если бы это было просто/очень нужно, уже бы давно сделали.
а где собственно изыскания на прерывания?
Немного чисел результатов оптимизации:
В сентябре 2025 влияние оптимизации сокращения полных путей до имени в Яндекс Браузере было такое:
При одновременном использовании cокращённых LOG и FROM_HERE скорость старта улучшается на 2% (146 мс) по результатам внутреннего теста производительности.
Замечу, что результат не статичен и меняется с течением времени от развития кодовой базы.
Также эффект от оптимизации может отличаться от проекта к проекту.
Оптимизация ещё интересна тем, что теперь её стало проще реализовать для получения выигрыша в других проектах.
Не очень понятно, как уменьшение размера на 0.06% так сильно влияет на скорость загрузки. У вас условно была библиотека 300Мб и осталась примерно столько же. Так все таки - за счет чего такой прирост производительности?
заметно уменьшить dll
0.06%
А разговоров то было...
Хотел бы покритиковать производительность Яндекс браузера на Android по сравнению с Chrome на s24, хром просто летает, особенно при свайпе назад на предыдущую страницу возвращается моментально без прогрузок, а ябраузер как-будто заново загружает предыдущую страницу, подлагивания при прогрузке рекламных блоков и видеовставки, на хроме все прекрасно. Отсутствие настроек для ограничения cockies, табло с вкладками, которое надо свайпить каждый раз вниз, дак еще табло перекрывает история и постоянно приходиться крестик нажимать, чтобы не мешало. Берите пример как должно выглядеть избранные у Самсунг браузера или сафари, нажал на адресную строку и вышло окно с закладками внизу. И еще вопрос насколько вы отстаете от последней версии движка хрома в разработке. Прошу прощения за сумбур и ошибки, пишу в дороге и на маленьком экране.
Это все, что вам нужно знать про текущий уровень разработки в яндексе.
Оказывается clang написан на C++, а не на ассемблере! И кто бы мог подумать?
Осталось только немного разобраться в вопросе как Windows на самом деле работает с exe и dll файлами.
С чего вы взяли что clang написан на ассемблере? Вас смущает, что компилятор для C++ написан на нем же самом?
Вот исходники, там cpp на h и cpp погоняет.
тоесть логировать можно через string_view{}? ведь лог пишется либо в терминал в output или в файл блоком байтов
вообще из-за пользовательского експириенса и прочих нюансов лучше сохранять пути указанные пользователем, странная оптимизация сокращать, то что должно быть, ну да в терминале ради оптимизации можно убрать все обозначения, а в емаксе убрать сверху тоже пару 10 символов в окне в названии, но оптимизация ли это
есть string_view{}, libz, draco сжатие :)
Как сокращение полных путей файлов в логах влияет на производительность и размер Браузера