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

186

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

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

Никлас Розенкранц
источник
134
Только в 4 раза больше ?! Это удивительно, учитывая, насколько современный браузер делает больше
Ричард Тингл,
23
В качестве примечания, я верю, что «есть какое-то правило, что программы забирают всю доступную память независимо от того, сколько это, но почему?» вероятно, относится к оперативной памяти, а не к физическому дисковому пространству, по крайней мере, так я бы это интерпретировал. Может быть не так.
Trotski94
103
Так что вы говорите, что программа, которая когда-то занимала место на жестком диске в 10 долларов, теперь занимает около 30 центов на жестком диске? Мне трудно об этом беспокоиться.
Эрик Липперт
49
«Программы не выполняют значительно больше функций» - добрый господин человек. Просто взгляните на спецификации HTML 4 и в CSS 1 спецификации (не волнуйтесь, я буду ждать - это не займет у Вас много времени , даже если вы читаете их). Netscape 4 даже не смог реализовать их должным образом. Только количество новых и безумных HTML и CSS, которые поддерживает Chrome, значительно. Плюс у него есть вкладки. И обновляется каждые шесть недель.
Пол Д. Уэйт
13
КСТАТИ. 50 МБ во времена Netscape были большими, но, к сведению, они включали не только веб-браузер, но также почтовый клиент и редактор HTML, и, возможно, даже что-то еще.
el.pescado

Ответы:

266

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

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

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

Килиан Фот
источник
120
Конкретными примерами того, что должен включать современный браузер, являются криптографические библиотеки, база данных Unicode, JIT-компилятор времени выполнения и оптимизации, видеокодеки, рендерер PDF, а также сложный механизм рендеринга и парсеры для всех поддерживаемых типов MIME. Это все складывается, но в отличие от игр браузеры не требуют большого количества ресурсов с высоким разрешением. Современная загрузка Firefox весит всего 40–50 МБ в сжатом виде.
Амон
23
«Результат будет потрясающе быстрым и приятным», - звучит как желаемое за действительное.
Док Браун
16
@amon Не забывайте, что браузеры также включают в себя другие типы ресурсов и целый API для плагинов и тому подобное. Они даже поставляются с инструментами отладки (профилировщики, сетевые анализаторы, инспекторы элементов, полнофункциональная консоль, отладчики и многое другое). Браузеры становятся ближе к целой операционной системе, чем мы все можем себе представить. Существует даже постоянное обсуждение использования веб-сборки! ОП должен быть поражен тонной дерьмом, которое они могут втиснуть в браузер.
Исмаэль Мигель
10
@IsmaelMiguel Что касается Chrome OS, браузеры уже являются целой операционной системой. ;-P
Ajedi32
111
tendency to spend less time on optimizing things for space Этот. Когда я пишу код, я не оптимизирую пространство или скорость. Я оптимизирую для обслуживания. Более важно, чтобы кодовая база могла легко изменяться, чем быть быстрой или маленькой. Я могу ожидать, что за каждую жалобу на скорость программы я получу десять запросов на новые функции и ноль запросов, чтобы сделать ее меньше.
user2023861
109

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

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

JacquesB
источник
12
Да, последние браузеры поддерживают анимацию, градиенты, эффекты фильтров изображений, JavaScript, 2D-графику (холст), 3D-графику с WebGL, генерацию аудио, геймпад (!), Декодирование видео, расширенное хранилище на стороне клиента, одноранговую связь (WebRTC), геолокация, WebSocket, WebCryptography, MIDI, доступ к микрофону / веб-камере, уведомлениям и т. Д.
ysdx
1
Добавьте больше работы (DOM, CSS, Javascript) к еще большему объему недвижимости (несколько мониторов, значительное увеличение разрешения: увеличение экранов компьютеров: с 1999 по 2011 годы ) - 800x600 против 1920x1080 против 4k ... 8k и далее ... Разрешение от 1080 до 4k в четыре раза больше, чем в 8 раз.
WernerCD,
7
@WernerCD Просто большой экран не требует большего двоичного файла. 32-битный значок размером 64 на 64 пикселя потребует одинакового места на диске, независимо от того, отображается ли он на мониторе 800x600 или 2560x1440. Изменение размера вашего окна не меняет размер двоичного файла. Что важно для дисплеев, так это то, что когда вы начинаете делать такие вещи, как удвоение пикселей, вам нужны большие ресурсы, чтобы продолжать выглядеть четкими (э).
8bittree
1
@ 8bittree, это может повысить требования к производительности программного обеспечения. А более производительный код может быть более сложным (например, веб-сайт, использующий Canvas, вероятно, нуждается в большей сложности и коде, чем веб-сайт, использующий SVG). Но да, ты в основном прав.
Пол Дрэйпер,
1
Хотя, безусловно, верно, что текущий HTML делает намного больше, чем HTML 3.2, сама спецификация также намного более детализирована, что добавляет значительный объем контента в спецификацию. Сравните длину описания EMэлемента в HTML 3.2 - целых восемь или девять слов - с длиной того же самого в спецификации HTML 5 - для меня, более чем полный экран, включающий окружающий материал, описывающий элемент, где это применимо и каково его предполагаемое использование.
CVn
79

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

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

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

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

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

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

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

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

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

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

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

Майк Накис
источник
17
Это правильный ответ. (В настоящее время) комментарии с более высоким рейтингом упоминают больше функциональности, но это не полностью объясняет увеличенный размер. Размер поступает от включенных библиотек, которые предоставляют эти функции.
user1936
5
@ IsmaelMiguel хорошо, я говорил о постоянных пользователях. Кроме того, игры являются особым случаем, потому что эти 35 ГБ в основном носители, а не код или библиотеки. Это просто медиа, которые вы можете просматривать только через специальное приложение - игру. Но даже для геймера 35 ГБ - ничто на сегодняшних мульти-терабайтных дисках. Во всяком случае, предположим, что если вы геймер, который настаивает на обладании небольшим диском, то вы далеко не представитель пользователей.
Майк Накис
2
@MikeNakis Не каждый геймер имеет диск объемом 1 ТБ или деньги, чтобы купить 256 ГБ SSD. У некоторых, как у меня, есть 128 ГБ SSD или ноутбук с объемом менее 500 ГБ. Некоторое время назад 80% моего пространства SSD было просто играми. Это были просто 3-4 игры, поедающие пространство. А в самой игре почти у каждого есть ноутбук и он играет на нем.
Исмаэль Мигель
5
@ Майк, это не важно. Когда мы говорим о размере приложения, мы имеем в виду либо размер загружаемого установочного файла, либо общее пространство, занимаемое приложением на диске после установки. Это включает в себя библиотеки, медиа, данные, все. И в настоящее время, чтобы избежать проблем несовместимости, приложения обычно поставляются вместе с большинством необходимых им библиотек, вместо того, чтобы надеяться, что библиотеки будут уже установлены и имеют правильную версию и т. Д. Размер основного исполняемого файла на самом деле не представляет никакого интереса или каких-либо последствий.
Майк Накис
3
@IsmaelMiguel Для программиста это, скорее всего, разные виртуальные машины, док-контейнеры и тому подобное. Нет лучшего вздора, чем умножение целых раздутых систем ;-)
cmaster
16

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

Eterm
источник
5
Я могу ошибаться, но я работаю в иллюзии, что струны - это наименьшая часть этой проблемы. Да, есть много языков, но количество строк, которые пользователь когда-либо видит, очень ограничено. В конце концов, один из самых надежных способов потерпеть неудачу в вашем пользовательском интерфейсе - это включить слишком много текста.
Мастер
5
В дополнение к тому, что сказал @cmaster, Firefox, в частности, не связывает полную локализацию (и пока я думаю об этом, как и OpenOffice.)
BenjiWiebe
2
@cmaster Strings, нет. Но локализованное видео и аудио, особенно в контексте игр? Во IIRC была игра объемом 60 ГБ (GTA V?), Где> 10 ГБ было исключительно локализованным звуком. Это значительный кусок.
Боб
@Bob Правильно, я не думал об играх, они, кажется, являются одним большим исключением из того, что я написал.
Учитель
Для каждого языка таблица строк может добавить до нескольких дополнительных K байтов. Только одни значки приложений обычно уменьшают общий размер всего строкового содержимого (возможными исключениями являются приложения со встроенными словарями)
andyb
13

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

Sharptooth
источник
Мне любопытно, почему за две ночи это произошло.
Sharp
6
Я не сделал, но я не думаю, что это действительно отвечает на вопрос достаточно подробно. Это просто говорит о том, что «программное обеспечение становится больше, потому что оно делает больше», и из других ответов вы увидите, что на самом деле есть нечто большее, чем это.
Гонки легкости на орбите
1
Связанный фактор заключается в том, что в системах, использующих статическое связывание, компоновщику может потребоваться только извлечение кода, который фактически используется [некоторые компоновщики всегда вытягивают все, но лучшие пытались быть избирательными]. При использовании динамического связывания, особенно если модули могут совместно использоваться, даже если для первого кода, устанавливающего модуль, требуется только одна функция из него, невозможно узнать, какие функции могут понадобиться другому коду, который хочет совместно использовать модуль.
Суперкат
@sharptooth Я даже больше не удивляюсь. В то время как в большинстве случаев система работает , я также вижу ужасно неправильно разбитые ответы получить upvoted как сумасшедшие и приняты , а правильные являются downvoted в Лету слишком часто ...
Брайан Knoblauch
10

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

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

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

Брайан Кноблаух
источник
3
Что такое дискета? ;)
500 - Внутренняя ошибка сервера
@ 500-InternalServerError Что такое Ада? : D
BenjiWiebe
3
для новичков дискета составляет около 1,4 МиБ
Sarge Borsch
3
Я видел современные исполняемые файлы Ады до 200 байт. Но если по умолчанию ваш компилятор использует такие вещи, как полнозадачная среда выполнения, независимо от того, используете вы задачи или нет, то следует ожидать 1 МБ или около того. И это обычно не стоит того, чтобы разбирать его.
Брайан Драммонд
@BrianDrummond, звучит как по-настоящему дурацкое время выполнения, или дрянное время выполнения, а также библиотека и компоновщик. В обучающем видео, которое я видел много лет назад, Джин Ичбиа и др. Упомянули, что типичная среда выполнения Ады (для оригинальной версии языка) будет около 4K. Из любопытства я проверил это по сравнению с пакетом времени выполнения TI 320C30, который мы использовали. Он был прав на деньги.
Джон Р. Штром
7

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

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

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

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

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

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

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

Mike76
источник
1
Эта последняя точка пули совершенно точно.
Гонки легкости на орбите
3
Я сделал в общей сложности одно приложение для Android, и APK составляет 0,05 МБ. Опять же, это не так много. Мне все еще интересно, почему приложение секундомера (с таким же количеством функций, как у меня, хотя и совершенно другое) занимает несколько МБ.
imibis
5
Последнее замечание неверно, разработчики все равно. Нам просто нужно манипулировать различными приоритетами, и придать этому приложению немного больше смысла.
NPSF3000,
Также не помогло то, что SDK (в то время) настаивал на добавлении библиотеки 5+ МБ в мое приложение размером 0,05 МБ, которое мне не нужно, и я должен был забыть удалить его перед сборкой релиза.
Имибис
4

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

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

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

andyb
источник
2
этот пост довольно трудно читать (стена текста). Не могли бы вы изменить его в лучшую форму?
Комнат
1
«10-кратный размер» Hello World требует «месяцев на разработку»? Стоит ли чистить зубы десять раз, стоя перед зеркалом без остановки в течение месяца?
bcrist
Чистка зубов x раз является линейной функцией от x, но программирование обычно не является линейной функцией. Если вы создаете каждую строку кода с использованием самых низкоуровневых функций языка, вы получаете быстрый и небольшой код, но с более высокой стоимостью за уровень сложности. Языки более высокого уровня больше раздуваются, но держат стоимость ближе к линейной функции сложности.
Andyb
2

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

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

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

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


источник
0

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

Qwertie
источник
-1

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

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

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

neoedmund
источник
Почему именно 5 голосов, а не один комментарий, объясняющий почему?
Кромстер
1
@KromStern В первом разделе описывается, как работают библиотеки, и очень непонятным образом при непоследовательном использовании code. Я бы сказал, что это не совсем отвечает на этот вопрос. Во втором разделе в качестве примера используется Java (хотя мы пытаемся утверждать, что JRE следует рассматривать как часть роста размера приложения), что опять-таки не соответствует сути вопроса и вовсе не является справедливым примером и продолжает увековечивать недоразумения Java). В целом это либо неверно, либо повторяет пункты предыдущих, лучше написанных ответов.
1
Ваш пример лесозаготовок к сети или файл не является хорошим либо - потому что с точки зрения Кодекса, как файлы и обрабатываются точно так же , как (разница между файлами и сетью осуществляется с помощью операционной системы). Мне еще предстоит увидеть каркас журналирования, который имеет «вход в базу данных» как часть своей основной функциональности, поскольку это будет осложнено драйверами Oracle и MySQL против Sql Server против Postgres против ... и диалектическими различиями.
@ user40980 Различие между файлом и сетью не обрабатывается операционной системой. Им нужны разные вызовы ОС для подключения и записи. Доступ к базе данных осуществляется через уровень независимости базы данных, такой как JDBC или libdbi. (Который, в свою очередь, может использовать драйверы для всех поддерживаемых баз данных!)
immibis
-2

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

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

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

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

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

Фил Ханнент
источник
3
Это совсем не то, о чем идет речь. Виртуальная память и сборщик мусора были только что изобретены, когда была написана эта цитата, и они не получили широкого распространения.
Йорг Миттаг,
-2

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

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

Пол Дж Абернати
источник
2
кажется, это не дает ничего существенного по сравнению с замечаниями, сделанными и объясненными в предыдущих 13 ответах
комнат
-3

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

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

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

daemondave
источник