Обновите представление Android

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

Я имею в виду то, что часто называют «встроенными системами», многие из которых в настоящее время все чаще используют операционные системы общего назначения, и эти системы используются для всего, что только можно себе представить.

Чрезвычайно распространенным примером являются устройства, использующие системы GNU / Linux, использующие Busybox . Я довел это до крайности с NetBSD , создав загрузочный образ системы i386 (32-разрядный), который включает в себя как ядро, так и его корневую файловую систему, причем последний содержит единственную статически-связанную (by crunchgen) двоичный файл с жесткими ссылками на все программы, который сам содержит все (по крайней мере, последний счет 274) стандартных полнофункциональных системных программ (большинство, кроме набора инструментов), и он меньше 20 мегабайт байтов (и, вероятно, работает очень удобно в системе с 64 МБ памяти (даже с несжатой корневой файловой системой и полностью в ОЗУ), хотя я не смог найти такой маленький для тестирования далее).

В более ранних публикациях упоминалось, что время запуска двоичных файлов со статической связью быстрее (и это может быть много быстрее), но это только часть картины, особенно когда весь объектный код связан с одним и тем же файлом, и особенно, когда операционная система поддерживает подкачку кода по требованию непосредственно из исполняемого файла. В этом идеальном сценарии время запуска программ буквально пренебрежимо мало, поскольку почти все страницы кода уже будут в памяти и будут использоваться оболочкой (и и init любыми другими фоновыми процессами, которые могут выполняться ), даже если запрошенная программа никогда не запускалась с момента загрузки, поскольку, возможно, для выполнения требований программы во время выполнения должна быть загружена только одна страница памяти.

1114 Однако это еще не вся история. Я также обычно собираю и использую установки операционной системы NetBSD для своих систем полной разработки, статически связывая все двоичные файлы. Несмотря на то, что для этого требуется значительно больше дискового пространства (всего ~ 6,6 ГБ для x86_64 со всем, включая набор инструментов и статическую привязку X11) (особенно если одна таблица полных символов отладки доступна для всех программ, другая ~ 2,5 ГБ), результат все равно остается в целом работает быстрее, а для некоторых задач даже использует меньше памяти, чем обычная система с динамической связью, которая предназначена для совместного использования кодовых страниц библиотеки. Диск дешев (даже быстрый диск), и память для кеширования часто используемых файлов на диске также относительно дешева, но циклы ЦП на самом деле не такие, и они платят ld.so стоимость запуска каждого процесса, который запускается каждый раз. его запуск займет часы и часы циклов ЦП от задач, требующих запуска многих процессов, особенно когда одни и те же программы используются снова и снова, например, компиляторы в системе разработки. Связанные со статическими данными программы могут сократить время сборки нескольких архитектур для всей системы на моих системах на часов . Мне еще предстоит встроить инструментальную цепочку в мой отдельный crunchgen двоичный файл, но я подозреваю, что когда я это сделаю, будет сэкономлено больше времени на сборку из-за выигрыша в кеше ЦП.