Почему статические библиотеки - это всего лишь пакет объектных файлов, без какой-либо обычной взаимозависимой оптимизации или переупорядочения? - PullRequest
1 голос
/ 07 ноября 2011

При связывании совместно используемой библиотеки (или, по крайней мере, библиотеки DLL Windows) возможна большая оптимизация, и все функции и классы объединяются и реорганизуются для достижения оптимальной производительности (или, как я думаю / надеюсь).

Почему статические библиотеки - это всего лишь пакет объектов? Не лучше ли компоновщику (как по времени, так и по производительности) иметь список переменных, функций, классов и т. Д., Содержащихся в объектных файлах, поэтому при связывании исполняемого файла или общего объекта, использующего эту библиотеку, можно прибыль от уже выполненного прохода оптимизации по взаимозависимым вещам в статической библиотеке?

Создание статической библиотеки не займет много времени (в любом случае будет возможно только ограниченное количество оптимизаций), но последующие этапы сборки с использованием этой библиотеки будут намного быстрее / оптимальными.

PS: Я в основном говорю здесь об оптимизации времени соединения, но, поскольку все популярные инструментальные цепочки гордятся этой возможностью, я уверен, что этот вопрос как-то всплывет? Пожалуйста, не отвечайте на этот вопрос: так было всегда, или совместимость, которую никто никогда не думал изменить. Это не то, что я ищу ...

Ответы [ 2 ]

1 голос
/ 06 декабря 2011

Конфликт между генерацией временного кода канала и оптимизацией перед соединением.

Предположим, что из этой библиотеки вы вызываете функцию Foo только один раз с фиксированным аргументом: Foo(12). LTCG теперь позволяет свести реализацию Foo () к этому единственному случаю, делая недействительными все оптимизации и информацию дерева вызовов, которую вы, возможно, ранее собрали.

Имея это в виду, только информация, которую Foo() делает не вызывает Bar(), может быть перенесена. Я не вижу, как это значительно уменьшило бы давление на стадии соединения.

Информация для заказа аналогичным образом подлежит оптимизации под руководством профилировщика: какие функции являются горячими точками, которые необходимо сгруппировать, можно определить только по окончательному двоичному файлу.


Обычно кажется, что оптимизация продвигается к стадии связывания, от предыдущих стадий - и хотя предложенные вами оптимизации осуществимы, вероятно, они не окупятся, если вы сравните их с количеством сценарии, в которых это можно использовать, и дополнительная сложность в коде (примерно пропорциональная количеству ошибок)

0 голосов
/ 06 декабря 2011

В этих файлах есть прототипы.Они, вероятно, действуют как список, который вы упомянули

...