Добрый час, нужны советы по решению сл. проблемы.
Есть проект статической библиотеки, достаточно большой, но я бы не сказал что уж слишком.
Проблема в том что он продюсит статическую библиотеку размером 1.6 Gb, что конечно же сказывается на линковке с конечным exe размер котрого получается около 100 Mb (это я сейчас говорю о цифрах для debug конфигурации), но тут проблема не в размерах а о во времени которое уходит на линковку.
Это примерно 1 час.
Я понимаю что со статической библиотекой почти ничего сделать нельзя. Инкрементальная линковка включена.
Сделать из нее dll что бы exe линковалась шустрее, не вариант (как мне кажется), библиотека находится в разработке и тогда проблема просто перенесётся на линковку dll.
Здравствуйте, nen777w, Вы писали:
N>Добрый час, нужны советы по решению сл. проблемы. N>Есть проект статической библиотеки, достаточно большой, но я бы не сказал что уж слишком. N>Проблема в том что он продюсит статическую библиотеку размером 1.6 Gb, что конечно же сказывается на линковке с конечным exe размер котрого получается около 100 Mb
Эти 1.6 гига — это что? исполняемый код? данные? дебаг-информация?
MD>Эти 1.6 гига — это что? исполняемый код? данные? дебаг-информация?
PDB она как и положенно генериться в отдельный файл, который кстати всего ~100 Mb.
Данных там нет, так что получается чистый код.
Смотрел кстати IDA самый жирный obj размером 34Mb там полно фнкций которые попали туда как я понимаю из include хидеров
, хотя сам исходник 16kb и почти ничего не содержит.
Здравствуйте, nen777w, Вы писали:
N>Добрый час, нужны советы по решению сл. проблемы. N>Есть проект статической библиотеки, достаточно большой, но я бы не сказал что уж слишком. N>Проблема в том что он продюсит статическую библиотеку размером 1.6 Gb
Здравствуйте, nen777w, Вы писали:
N>Что еще можно сделать?
Можно попробовать Unity Builds — сгруппировать Translation Units в укрупнённые TU. Могут потребоваться небольшие правки кода, так как местами меняется семантика.
Это:
* ускорит компиляцию — заголовчные файлы обрабатываются меньшее количество раз, воплощения шаблонов переиспользуются.
* уменьшит размер статической библиотеки — одинаковый скомпилированный код не будет дублироваться между мелкими объектными файлами. Сейчас проверил на одном проекте — включение Unity Builds уменьшает размер крупной статический библиотеки в два раза. Я предполагаю (но не тестировал), что это также сократит время линковки в финальный executable.
Создание Unity Builds легко автоматизируется системой сборки — достаточно лисапеда на пару десятков строк. Для CMake есть Cotire, который автоматом делает Unity Builds.
N>>Что еще можно сделать?
EP>Можно попробовать Unity Builds — сгруппировать Translation Units в укрупнённые TU. Могут потребоваться небольшие правки кода, так как местами меняется семантика. EP>Это: EP>* ускорит компиляцию — заголовчные файлы обрабатываются меньшее количество раз, воплощения шаблонов переиспользуются. EP>* уменьшит размер статической библиотеки — одинаковый скомпилированный код не будет дублироваться между мелкими объектными файлами. Сейчас проверил на одном проекте — включение Unity Builds уменьшает размер крупной статический библиотеки в два раза. Я предполагаю (но не тестировал), что это также сократит время линковки в финальный executable.
EP>Создание Unity Builds легко автоматизируется системой сборки — достаточно лисапеда на пару десятков строк. Для CMake есть Cotire, который автоматом делает Unity Builds.
Спасибо!
Попробовал только что на группе самых жирных obj файлов c сумарным размером в 109Mb.
В результате из начальных 1 952 033 572 либа стала 1 938 606 498 т.е. имеем экономию в 13 427 074 так что что то в этом определённо есть.
Сейчас попробую зайти со стороны cmake.
Интересно на сколько уменьшитья время линковки.
Здравствуйте, nen777w, Вы писали:
N>Намекаете на шаблоны. Да их много, но они мелкие по sizeof().
Это никакого отношения к расбуханию не имеет. Надо смотреть в каком количестве они интстансируются с разными параметрами.
Например, если у вас есть самописный контейнер который использутся со 100 разными типами у вас фактически 100 разных новых классов, которые увеличивают объем бибилиотеки.
Здравствуйте, ML380, Вы писали:
ML>Здравствуйте, nen777w, Вы писали:
N>>Намекаете на шаблоны. Да их много, но они мелкие по sizeof(). ML>Это никакого отношения к расбуханию не имеет. Надо смотреть в каком количестве они интстансируются с разными параметрами.
ML>Например, если у вас есть самописный контейнер который использутся со 100 разными типами у вас фактически 100 разных новых классов, которые увеличивают объем бибилиотеки.
Так я это и имел в виду. Потяное дело что шаблон сам по себе всего лишь шаблон.
Шаблонов много, но они мелкие все, но это так... на глаз, хотя конечно надо деталнее в цифрах проанализировать.
EP>Создание Unity Builds легко автоматизируется системой сборки — достаточно лисапеда на пару десятков строк. Для CMake есть Cotire, который автоматом делает Unity Builds.
Рапортую: Либа с 1.9Gb похудела до 1Gb, время линковки с 1 часа до 2 мин 21 сек.
Так что еще раз спасибо за подсказку cotire!
