Время загрузки для общих библиотек по сравнению со статическими библиотеками
У меня есть вопрос на общих библиотеках по сравнению со статическим временем загрузки библиотек.
Предположите, что у меня есть исполняемый foo.exe, который использует liba, libb, libc. Также в установленный срок существует больше чем 10 экземпляров исполняемого файла, работающего на машине.
Теперь, если вышеупомянутые 3 библиотеки были совместно использованными библиотеками: 1-й Insance загружается в RAM: потраченное время будет временем, потраченным основным () foo.exe, чтобы быть загруженной памятью (принимающий его незначительное) + время загрузить liba + время для загрузки libb +, время для загрузки libc 2-го экземпляра запускается: Теперь предположите, что второй экземпляр этого исполняемого файла выполняется. Так как все библиотеки уже загружаются в оперативную память, потраченное время только для загрузки основного () к памяти, которая незначительна.
Теперь, если вышеупомянутые 3 библиотеки были статическими библиотеками: 1-й Insance загружается в RAM: потраченное время будет временем, потраченным основным () foo.exe, чтобы быть загруженной памятью (принимающий его незначительное) + время загрузить liba + время для загрузки libb + время для загрузки libc (Offcourse его теперь вся часть исполняемого файла в целом), 2-й экземпляр запускается: Теперь предположите, что второй экземпляр этого исполняемого файла выполняется. Потраченное время будет снова временем, потраченным основным () foo.exe, чтобы быть загруженной памятью (принимающий его незначительное) + время загрузить liba + время для загрузки libb + время для загрузки libc. (Так как каждая исполняемая доля наклона librareies, поскольку это статический librareies),
Таким образом, мое заключение состоит в том, что со статической библиотекой время загрузки будет больше. Но мне сказали, что совместно использованные библиотеки занимают больше времени во время загрузки, чем статические библиотеки, таким образом, будет задержка и таким образом, совместно использованные библиотеки не будут хорошим вариантом. Как это возможно?
3 ответа
Создание ссылок (разрешение ссылок) не является бесплатным. При статической компоновке разрешение выполняется раз и навсегда при генерации двоичного файла. При динамической компоновке это нужно делать каждый раз при загрузке двоичного файла. Не говоря уже о том, что код, скомпилированный для запуска в общей библиотеке, может быть менее эффективным, чем код, скомпилированный для статической компоновки. Точная стоимость зависит от архитектуры и реализации динамического связывания в системе.
Стоимость создания динамической библиотеки может быть относительно высокой для 32-разрядного набора инструкций x86: в двоичном формате ELF один из и без того скудных регистров должен быть принесен в жертву для создания динамически связанного кода. перемещаемый. В более старом формате a.out каждая разделяемая библиотека размещалась в фиксированном месте, но это не масштабировалось. Я считаю, что в Mac OS X была промежуточная система, когда динамические библиотеки размещались в заранее определенных местах в адресном пространстве, но конфликты разрешались в масштабе отдельного компьютера (длительная фаза «Оптимизация производительности системы» после установки новых программного обеспечения). В некотором смысле эта система (называемая предварительным связыванием ) позволяет вам есть свой пирог и есть его. Я не знаю, нужна ли предварительная привязка сейчас, когда Apple в значительной степени перешла на архитектуру amd64.
Кроме того, в современной ОС и статически, и динамически связанный код загружается (выгружается) с диска только в том случае, если он используется, но это довольно ортогонально вашему вопросу.
Большое спасибо за эту невероятно быструю реакцию. у нас есть 2 архитектурных сценарных :
Q1. Architecure-1 :Предположим размер exe 3GB (статические библиотеки). 95% - это библиотеки и 5% main(). При таком огромном размере загрузка этого экзового файла займет больше времени (в предположении, что статические библиотеки) или линковка этого экзового файла займет больше времени (в предположении, что используются разделяемые библиотеки, и если все библиотеки уже находятся в памяти, то линковка должна быть выполнена)
Architecure-2 :Предположим, что у меня есть exe размером 1.5Гб (95% lib + 5% main()), и 6 экземпляров этого экзового файла выполняются одновременно. После того, как эти 6 экземпляров будут запущены в течение нескольких дней, предположим, что мы готовы принять дополнительную задержку при начальной загрузке+ссылке этих 6 экземпляров.
Q2. Теперь, если я использую общие объекты, а не статические объекты, у меня будет много свободного места в оперативной памяти, так как все библиотеки распределены между 6 экземплярами, я не буду ускорять выполнение в реальном времени из-за большего места в оперативной памяти, что уменьшает подмену страниц ?
Q3. Если я использую map-файлы для уменьшения количества экспортируемых символов (что возможно только при использовании разделяемых библиотек), размер таблицы символов не уменьшится и не улучшится скорость выполнения ?
Q3. Внезапно
Архитектура открытых служб Windows (WOSA): http://en.wikipedia.org/wiki/Windows_Open_Services_Architecture
Основа ODBC, MAPI, TAPI и т.д.
-121--1002530-Кажется, что вам нужно перенять эволюционное прототипирование. Тем не менее, чтобы помочь противостоять некоторым из тех, что вы чувствуете, когда они делают еще один запрос на изменение, вы должны сказать «Да, но это задержит проект на X дней/недель/месяцев и увеличит затраты на сумму Y». Если они рады платить, будьте счастливы работать. «Они платят» - уважительная причина.
-121--3579372-Статические библиотеки связываются во время компиляции, общие библиотеки связываются во время выполнения. Поэтому исполняемые файлы, использующие статические библиотеки, амортизируют все свое время связи перед даже записью на диск.