Увеличение размера библиотеки при компиляции всех исходников одним файлом?
Решил провести эксперимент — объединить все исходники в библиотеке в один файл и собрать библиотеку из него. По идее, должно значительно ускорить компиляцию и, теоретически, улучшить работу оптимизатора.
Взял пару библиотек (порядка 20-40 исходников в каждой), и собрал по-старому и по-новому.
Среда: Linux (RHEL), g++ 3.4.6
Время компиляции ускорилось и не ускорилось одновременно :-)
Значительно — примерно в 4 раза уменьшилось время затраченного CPU.
При этом, так как билд очень хорошо паралелит компиляцию исходников (на машине 4 ядра), то разница в затраченном времени (по часам) была невелика. Реальное время компиляции уменьшилось всего процентов на 10.
Я так понимаю, что на машинах с одним CPU эффект будет классный (если компилятору хватит памяти справиться с огромным исходным файлом).
Теперь о размере получаемой библиотеки — я ожидал, что он уменьшится — там же должно быть раздолье для оптимизации. На деле библиотека вырастала на 10% если сборка велась из одного здорового исходника. И вот это-то мне и не понятно… Я-то думал она меньше станет…
При этом, если взять только объектные файлы, то как раз их объем сильно в размере уменьшается — один большой объектный файл занимает в 1.5-2 раза меньше, чем суммарно маленькие — это как раз ожидаемо.
Вопрос: чем может быть вызвано увеличение размера библиотеки?
И чем можно в библиотеку потыкать, чтобы понять, откуда размер? (nm, objdump, etc.?)
У меня пока единственное подозрение на «более эффективный» inline… или, может, что-то с шаблонами?..
так в том и прикол — суммарно объектные файлы скомпилированных файлов по отдельности занимают значительно больше, чем большой объединенный (350 кил против 220, если не ошибаюсь). Однако результирующая библиотека (до или после стрипа — не важно), из одного большого объектного файла получается больше. Дебаг ни при чем — с дебагом разница будет не в 10%, а в разы.
Скорее всего. как предыдущий товарищ написал, дело в инлайне.
