Почему размеры программ такие большие?

Если мы посмотрим на старую программу Netscape Navigator или более раннюю версию Microsoft Word, размер этих программ был менее 50 МБ. Теперь, когда я устанавливаю Google Chrome, он равен 200 МБ, а версия Slack для настольных компьютеров - 300 МБ. Я читал о каком-то правиле, согласно которому программы занимают всю доступную память, независимо от того, сколько это, но почему?

Почему текущие размеры программ настолько велики по сравнению с 10 или 15 лет назад? Программы не выполняют значительно больше функций и не выглядят совсем иначе. Что такое ресурсный боров сейчас?

«Очень разные» - это вопрос восприятия. Современная графика должна выглядеть хорошо при совершенно других разрешениях экрана, чем раньше, в результате чего изображение 100x100, которое раньше было более чем достаточно для логотипа, теперь будет выглядеть ужасно липким. Это должно было быть заменено изображением 1000x1000 того же самого, что в 100 раз. (Я знаю, что вместо этого вы можете использовать векторную графику, но это только подчеркивает: код рендеринга векторной графики нужно было добавлять в системы, в которых он раньше не был нужен, так что это всего лишь компромисс из одного вида увеличения размера другому.)

«Работа по-другому» также является вопросом восприятия. Сегодня браузер делает массово больше вещей , чем один из 1995 (Попробуйте серфинг в Интернете с историческим ноутбук один дождливый день. - вы увидите , что почти непригодным для использования) Не многие из них используются очень много, и использование может быть совершенно не знают 90 % из них, но они есть.

Помимо этого, конечно же, общая тенденция тратить меньше времени на оптимизацию пространства и больше на внедрение новых функций. Это естественный побочный эффект больших, более быстрых и дешевых компьютеров для всех. Да, можно было бы написать программы, которые были бы столь же эффективными с точки зрения ресурсов, как и в 1990 году, и результат был бы потрясающе быстрым и изящным. Но это больше не будет экономически эффективным; Вашему браузеру понадобится десять лет, чтобы к этому времени требования полностью изменились. Люди привыкли программировать с предельным вниманием к эффективности, потому что медленные, маленькие машины прошлого года заставляли их, и все остальные делали это также. Как только это изменилось, узкое место для успеха программы перешло от возможности работать вообще к выполнениювсе больше и больше блестящих вещей , и вот где мы сейчас.

Если вы сравните Netscape Navigator с современным браузером, функциональность будет огромной . Просто сравните спецификацию HTML 3.2 (51 страница, когда я делаю предварительный просмотр) с текущей спецификацией HTML (версия PDF - 1155 страниц). Это увеличение в 20 раз.

Netscape Navigator не имел DOM и не имел CSS! В документе не было динамических изменений, не было JavaScript, модифицирующего DOM или таблицы стилей. Нет вкладок. Нет аудио или видео. Современный браузер - гораздо более сложная программа.

Одна из причин заключается в том, что данные, упакованные в приложения, имеют больший размер, поскольку они имеют более высокое разрешение и качество. Во времена Netscape значок был не более 32x32 пикселей, с глубиной не более 8 бит (возможно, только 4), в то время как сейчас это, вероятно, что-то вроде 64x64, и это настоящий цвет с прозрачностью, то есть 32-битная глубина. Это в 16 раз больше. А пространство настолько дешево, что люди часто даже не удосуживаются проверить «сжатый» вариант при создании PNG.

Другая причина заключается в том, что в наши дни приложения несут ошеломляющий объем данных, чего не было в старых приложениях. Сегодня существуют приложения, которые поставляются вместе с презентацией «Начало работы» в видео .

Другая причина заключается в том, что современные языки программирования, как правило, сочетаются с богатыми средами выполнения, которые достаточно велики, до 100 МБ каждая. Даже если вы не используете все функции вашей среды выполнения, вам все равно придется упаковывать все это вместе с вашим приложением.

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

• Стоит ли включать еще одну библиотеку, если она будет использоваться только одной из моих функций? - да

• Стоит ли включать еще одну библиотеку, если мне нужно лишь небольшое подмножество всего богатства функциональных возможностей, предлагаемых этой библиотекой? - да

• Стоит ли включать еще одну библиотеку, если ее включение спасет меня только от 2 дней работы? - да

• Стоит ли включать несколько библиотек, которые служат более или менее одной и той же цели только потому, что разные программисты в моей платежной ведомости уже знакомы с разными библиотеками? - да

  (Обратите внимание, что я просто наблюдаю за этими тенденциями, я не делаю никаких заявлений относительно того, согласен ли я с ними или нет).

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

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

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

Одна из причин - это зависимости. Программе с богатым функционалом и привлекательной внешностью нужно много чего сделать - шифрование, проверка орфографии, работа с XML и JSON, редактирование текста и многое другое. Откуда они взялись? Может быть, вы катите свои собственные и держите их как можно меньше. Скорее всего, вы используете сторонние компоненты (возможно, лицензированные MIT с открытым исходным кодом), которые обладают множеством функциональных возможностей, которые вам на самом деле никогда не нужны, но как только вам нужна отдельная функция от стороннего компонента, вам часто приходится носить с собой весь компонент. Таким образом, вы добавляете все больше и больше зависимостей, и по мере того, как они сами развиваются и расширяются, ваша программа, которая зависит от них, также растет.

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

Пример того, как маленький код все еще может быть: MenuetOS, полноценная 64-битная ОС с мощными приложениями, которые помещаются на одну дискету.

Пример того, какой большой код может быть без видимой причины: я сделал простой текстовый вывод "Hello, World!" в аде недавно. Скомпилированный исполняемый файл был больше 1 МБ !. Один и тот же исполняемый файл в сборке - это просто KiB или 2 (и большая часть этого - исполняемые накладные расходы, фактический исполняемый код составляет десятки байтов).

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

• Языки более высокого уровня позволяют выражать идеи в меньшем количестве кода и времени, чем раньше. Эта пониженная сложность, наоборот, позволяет выражать все более сложные идеи.
• Объединение большего количества данных с приложением может сделать его более удобным для использования. Например, вероятно, пройдет совсем немного времени, прежде чем приложения для проверки орфографии будут поставляться в комплекте со всеми известными человечеству языками - в конце концов, всего несколько гигабайт.
• Аппаратные компромиссы предоставляют разработчикам и пользователям больше выбора, какой ресурс им нужен. Смотрите, например, FLAC / OGG против WAV, SVG против PNG, индексы базы данных.
• Гуманные интерфейсы часто компенсируют то, что ранее составляло огромное количество оборудования для удобства использования. Сглаживание, высокое разрешение, быстрое обновление и перелистывание между дискретными панелями - все это обеспечивает более реалистичный и, следовательно, интуитивно понятный и удобный опыт.

Это определенно верно в отношении приложений для Android. Четыре года назад простое приложение занимало около 2-5 мегабайт. В настоящее время простое приложение занимает около 10-20 мегабайт.

Чем больше свободного места, тем больше размер приложения.

Я думаю, что есть две основные причины в случае Android:

• Google расширил фреймворк Android, добавил много нового функционала.

• Разработчикам все равно. Изображения включаются в гораздо более высокое разрешение (конечно, увеличилось разрешение экрана смартфона), сторонние библиотеки включены бездумно.

Многое из этого сводится к времени разработчика и стоимости этого времени. В те времена, когда Visual Basic впервые появился на рынке, он конкурировал с C / C ++, и большим препятствием для этого было то, что вы могли написать «Hello World» на ANSI C для Windows, возможно, в 15 КБ. Проблема с VB заключалась в том, что у вас всегда был альбатрос библиотеки времени выполнения 300K.

Теперь вы можете увеличить размер вашей VB-программы в 10 раз, и это все равно будет всего на несколько K больше, но в 10 раз больше, чем ваша программа на C / C ++, и вы ожидаете развития на несколько МЕСЯЦЕВ.

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

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

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

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

Все это означает добавление новых слоев приложений (кода), безопасности и иногда оборудования.

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

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

Может быть, не тот случай, но что-то вроде этого: если вам просто нужно напечатать «hello world» на консоли с использованием Java, вам нужно установить JRE (> 60MB).

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

Я читал о каком-то правиле, согласно которому программы занимают всю доступную память, независимо от того, сколько это, но почему?

Это не совсем так. Системы не будут освобождать память, которую они использовали, пока операционная система не окажется под давлением памяти. Это улучшение производительности. Если вы просматривали страницу с изображениями, вы уходите. Вы можете вернуться назад, поэтому вам понадобится изображение снова. Если операционная система имеет ОЗУ, нет смысла очищать ее, пока вы не будете уверены, что она вам больше не понадобится.

Немедленная очистка памяти отнимает у пользователя циклы ЦП и пропускную способность памяти, когда они, скорее всего, хотят, чтобы веб-страницы с высокой чувствительностью отображались на экране.

Операционная система будет использовать всю доступную память вне приложения, большая часть которой предназначена для кэша файловой системы.

Управление памятью - сложная проблема, но над ней постоянно работают очень умные люди. Ничего не пропадает нарочно, и главная цель - предоставить вам очень отзывчивый компьютер.

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

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

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

Просто пройдитесь по стандартному коду C ++, чтобы увидеть все вызовы объекта assert () ed, чтобы убедиться, что они являются допустимыми объектами. Когда вы создаете слой за слоем объектов, инкапсулирующих объекты, нижние слои становятся раздутыми и непрозрачными. Программисты становятся ленивыми и берут больше объектов, потому что это быстрее, чем перепроектировать то, что ограничено необходимой функциональностью. Это действительно так просто.

Рассмотрим размер ядра Linux C, только ядро, в сравнении с размером сделанных на заказ приложений. Ядро может запустить всю машину. Но он не был построен так же быстро, как приложения, он требует времени, чтобы сделать лучшую функциональность.