Общие объекты над головой - PullRequest
5 голосов
/ 19 октября 2011

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

Каково ваше мнение по этому поводу?

С наилучшими пожеланиями,

Пол

Ответы [ 3 ]

7 голосов
/ 19 октября 2011

Стоимость общих библиотек примерно (на библиотеку):

  • Как минимум 4 КБ личной грязной памяти.
  • Не менее 12 КБ виртуального адресного пространства.
  • Несколько системных вызовов доступа к файловой системе, mmap и mprotect системных вызовов и, по крайней мере, одна ошибка страницы во время загрузки.
  • Время для разрешения ссылок на символы в коде библиотеки.

Плюс код, не зависящий от позиции:

  • Потеря одного регистра общего назначения (это может быть огромным для x86 (32-битного), но в большинстве случаев не имеет значения для других арок).
  • Дополнительный уровень косвенного доступа к глобальным / статическим переменным (и константам).

Если у вас большое долгосрочное приложение, затраты могут для вас вообще не иметь значения, если вы не используете крошечную встроенную систему. С другой стороны, если вы пишете что-то, что может быть вызвано много раз для коротких задач (например, переводчик языка), эти затраты могут быть огромными. Размещение всех стандартных модулей в их собственных .so файлах вместо статического связывания их по умолчанию - огромная часть того, почему Perl, Python и т. Д. Запускаются так медленно.

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

5 голосов
/ 19 октября 2011

Если объем памяти не равен крайне , размер одной копии этих файлов не является основным определяющим фактором.Учитывая, что это встроенная система, вы, вероятно, хорошо представляете, какие приложения будут использовать ваши библиотеки и когда.Если ваше приложение открывает и закрывает несколько библиотек, на которые оно должным образом ссылается, и вы никогда не открываете все библиотеки одновременно, то общая библиотека значительно экономит ОЗУ.снижение производительности.Открытие общей библиотеки занимает небольшое (обычно тривиальное) время;Если у вас очень медленный процессор или жесткие требования в реальном времени, статическая библиотека не будет подвергаться штрафу за загрузку совместно используемой библиотеки.Профиль, чтобы определить, важно это или нет.

Подводя итог, можно сказать, что совместно используемые библиотеки в некоторых особых случаях могут быть значительно лучше, чем статические.В большинстве случаев они приносят мало вреда.В простых ситуациях вы не получаете преимуществ от разделяемых библиотек.


Конечно, разделяемая библиотека значительно сэкономит во Flash, если у вас есть несколько приложений (или версий вашего приложения), которые используют одни и те жебиблиотека.Если вы используете статическую библиотеку, одна копия (размером примерно с общую библиотеку [1]) будет скомпилирована в каждую.Это полезно, когда вы находитесь на рабочей станции ПК.Но ты знал это.Вы работаете с библиотекой, которая используется только одним приложением.


[1] Разница в памяти отдельных файлов библиотеки невелика.Общие библиотеки добавляют таблицу индексов и символов, так что dlopen(3) может загрузить библиотеку.Важность этого зависит от вашего варианта использования;скомпилируйте для каждого, а затем сравните размеры, чтобы определить, что меньше во Flash.Вам нужно будет запустить и профилировать, чтобы определить, какое из них потребляет больше оперативной памяти;они должны быть похожими, за исключением начальной загрузки общей библиотеки.

1 голос
/ 19 октября 2011

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

Я предлагаю вам попробовать обе альтернативы и измерить используемое пространство как во FLASH, так и в RAM, а затем решить, какой из них лучше.

...