Почему размеры программ настолько велики?

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

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

184 голоса | спросил Niklas Rosencrantz 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 10:24:51 +0300 2015, 10:24:51

15 ответов


264

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

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

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

ответил Kilian Foth 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 10:33:59 +0300 2015, 10:33:59
108

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

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

ответил JacquesB 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 10:46:14 +0300 2015, 10:46:14
79

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

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

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

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

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

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

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

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

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

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

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

ответил Mike Nakis 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 12:30:29 +0300 2015, 12:30:29
16

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

ответил Eterm 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 11:32:24 +0300 2015, 11:32:24
13

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

ответил sharptooth 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 14:41:11 +0300 2015, 14:41:11
10

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

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

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

ответил Brian Knoblauch 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 17:09:04 +0300 2015, 17:09:04
7

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

  • Языки более высокого уровня позволяют выражать идеи в меньшем количестве кода и amp; чем раньше. Эта пониженная сложность, наоборот, позволяет выражать все более сложные идеи.
  • Связывание больше данных с приложением может сделать его более удобным для использования. Например, вероятно, это не заставит долго ждать, пока приложения для проверки орфографии не будут включены в список всех языков, известных человечеству. В конце концов, это всего лишь несколько гигабайт.
  • Компоновка оборудования позволяет разработчикам и пользователям больше выбирать, в каком ресурсе они заботятся. См., Например, FLAC /OGG vs WAV, SVG и PNG, индексы базы данных.
  • Гуманные интерфейсы часто компрометируют то, что ранее составляло бы огромное количество аппаратного обеспечения для удобства использования. Сглаживание, высокое разрешение, быстрое обновление и прокрутка между тем, что составляет дискретные панели, все это делает более реалистичным и, следовательно, интуитивным и относительным, опыт.
ответил l0b0 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 15:06:08 +0300 2015, 15:06:08
6

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

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

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

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

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

ответил Mike76 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 10:03:06 +0300 2015, 10:03:06
4

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

Теперь вы можете в 10 раз увеличить размер вашей VB-программы, и все равно будет всего лишь несколько килограммов, но в 10 раз больше, чем ваша программа на C /C ++, и вы посмотрите на несколько месяцев, больше разработки.

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

ответил andyb 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 07:54:37 +0300 2015, 07:54:37
2

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

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

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

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

ответил 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 11:11:28 +0300 2015, 11:11:28
0

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

ответил Qwertie 2 SatEurope/Moscow2017-12-02T12:34:30+03:00Europe/Moscow12bEurope/MoscowSat, 02 Dec 2017 12:34:30 +0300 2017, 12:34:30
-1

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

Возможно, не тот же случай, но что-то вроде этого: если вам просто нужно напечатать «hello world» на консоли с помощью Java, вам понадобится JRE (& gt; 60 МБ).

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

ответил neoedmund 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 09:40:03 +0300 2015, 09:40:03
-2
  

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

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

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

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

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

ответил Phil Hannent 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 24 Sep 2015 17:49:14 +0300 2015, 17:49:14
-2

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

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

ответил Paul J Abernathy 28 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 28 Sep 2015 16:32:06 +0300 2015, 16:32:06
-3

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

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

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

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132