С профилированием нужно быть аккуратным. На моем проекте оверхед был почти в два раза. Для дебага этапов и понимания на верхнем уровне, что происходит - хорошая вещь. А так по итогу пришлось расставлять таймеры вручную на функции.
В какой-то момент проблема перестаёт затыкаться железом, если мы говорим про локальные сборки. Может помочь распределённая компиляция и кеши, например Incredibuild. Но тут нужно смотреть на стоимость лицензий. Да и весь отдел должен находиться локально в одном офисе.
Нужно ли каждый раз собирать с нуля проект, после подтягивания репы? Даже если вы генерируете файлы, обычно правильная настройка add_custom_command в CMake позволяет отдать триггеры ребилда на откуп билд системе. В DEPENDS или в DEPFILE прописываются конфиги и перегенерация хедеров будет происходить только при изменении конфигов. https://blog.kangz.net/posts/2016/05/26/integrating-a-code-generator-with-cmake/ По моему опыту использования проблем с таким подходом нет, но может у вас что-то сильно экзотическое.
Вы часто собираете релизные билды локально? Как так вышло, что lto попал в локальные билды разработчикам?
Нет ли проблем в процессе с выключенными аналзаторами? Вроде работа сделана, ПР залит в дев ветку, после сборки на агенте ещё ПР делать на исправление)
На билд агентах не используете unity батчинг? Локально, как я понял, не используете.
«На некоторые проблемы многопоточности userver понятную диагностику по их исправлению на этапе компиляции» Какие конкретные проблемы? Дайте пример или ткните в код в репозитории, пожалуйста)
Спасибо за комментарий!
Могу сказать, что последние статьи тоже нелегко дались. Но в целом осталось приятное впечатление, особенно от обзора и сравнения других реализаций. Очень уж интересно!
Согласен с вами так же, насчёт крутости его фреймворка) Я больше был поражён наличию вики и документации на doxygen. Мне кажется не каждая библиотека может похвастаться таким.
И если вы имеете в виду майков, то у них в целом большой список используемых open source технологий, и обделённым остаётся не только автор EnTT. Но на то это free software.
С профилированием нужно быть аккуратным. На моем проекте оверхед был почти в два раза. Для дебага этапов и понимания на верхнем уровне, что происходит - хорошая вещь. А так по итогу пришлось расставлять таймеры вручную на функции.
В какой-то момент проблема перестаёт затыкаться железом, если мы говорим про локальные сборки. Может помочь распределённая компиляция и кеши, например Incredibuild. Но тут нужно смотреть на стоимость лицензий. Да и весь отдел должен находиться локально в одном офисе.
Нужно ли каждый раз собирать с нуля проект, после подтягивания репы? Даже если вы генерируете файлы, обычно правильная настройка add_custom_command в CMake позволяет отдать триггеры ребилда на откуп билд системе. В DEPENDS или в DEPFILE прописываются конфиги и перегенерация хедеров будет происходить только при изменении конфигов. https://blog.kangz.net/posts/2016/05/26/integrating-a-code-generator-with-cmake/
По моему опыту использования проблем с таким подходом нет, но может у вас что-то сильно экзотическое.
Статья классная, поставил плюс) Сам хотел поделиться опытом использования тулинга по профайлингу компиляции, но Вы опередили.
По pch - если архитектура проекта позволяет, можно использовать SHARED_PCH, экономя место на диске и переиспользуя pch между таргетами.
У -ftime-trace clang есть проблема с агрегацией данных по всем файлам. Удобно использовать такую утилиту:
https://github.com/aras-p/ClangBuildAnalyzer
Для сборки сninja скрипт построит flamegraph со всеми файлами:
https://github.com/nico/ninjatracing
После прочтения появились вопросы:
Вы часто собираете релизные билды локально? Как так вышло, что lto попал в локальные билды разработчикам?
Нет ли проблем в процессе с выключенными аналзаторами? Вроде работа сделана, ПР залит в дев ветку, после сборки на агенте ещё ПР делать на исправление)
На билд агентах не используете unity батчинг? Локально, как я понял, не используете.
Пробовали ли extern template?
По рефлексии в анриале есть статья
https://habr.com/ru/articles/690662/
«На некоторые проблемы многопоточности userver понятную диагностику по их исправлению на этапе компиляции»
Какие конкретные проблемы? Дайте пример или ткните в код в репозитории, пожалуйста)
Не вчитался в issue. Спасибо большое за уточнение и за то, что пролили свет на историю.
Спасибо за комментарий! Рад стараться!
Спасибо за комментарий!
Могу сказать, что последние статьи тоже нелегко дались. Но в целом осталось приятное впечатление, особенно от обзора и сравнения других реализаций. Очень уж интересно!
Согласен с вами так же, насчёт крутости его фреймворка) Я больше был поражён наличию вики и документации на doxygen. Мне кажется не каждая библиотека может похвастаться таким.
Насчёт поддержки, у автора eсть
PatreonGithub Sponsors.И если вы имеете в виду майков, то у них в целом большой список используемых open source технологий, и обделённым остаётся не только автор EnTT. Но на то это free software.