Чому розміри програм такі великі?

Якщо ми подивимось на вінтажну програму Netscape Navigator або ранню версію Microsoft Word, ці програми мали розмір менше 50 Мб. Тепер, коли я встановлюю google chrome, це 200 Мб, а версія для Slack настільна - 300 Мб. Я читав про якесь правило, що програми займуть усю наявну пам'ять незалежно від того, скільки вона є, але чому?

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

"Дивитись зовсім по-іншому" - це питання сприйняття. Сьогоднішня графіка повинна добре виглядати в абсолютно інших дозволах екрана, ніж раніше, в результаті чого зображення розміром 100x100, яке раніше було достатньо хорошим для логотипу, тепер виглядатиме жахливо липким. Її довелося замінити зображенням 1000х1000 тієї самої речі, що є коефіцієнтом 100 прямо там. (Я знаю, що ви можете використовувати векторну графіку замість цього, але це лише підкреслює сенс - код візуалізації векторної графіки потрібно було додати до систем, яким вона раніше не потрібна, тому це лише компроміс від одного виду збільшення розміру до іншого.)

"Робота по-іншому" - це також питання сприйняття. Сьогодні браузер робить масово більше речей , ніж один з 1995 (Спробуйте серфінг в Інтернеті з історичним ноутбук один дощовий день. - ви побачите , що майже непридатним для використання) Мало хто з них використовуються дуже багато, і використання може бути абсолютно не знають 90 % з них, але вони там.

Крім цього, звичайно, загальна тенденція витрачати менше часу на оптимізацію речей для простору та більше на впровадження нових функцій. Це природна побічна дія більших, швидших, дешевших комп'ютерів для всіх. Так, можна було б написати програми, які є такими ж ефективними, як і в 1990 році, і результат був би приголомшливо швидким і гладким. Але це вже не було б рентабельно; Вашому браузеру знадобиться десять років, до цього часу вимоги повністю змінилися б. Люди звикли програмувати з надзвичайною увагою ефективність, тому що повільні, маленькі машини минулого року змушували їх робити, і це робили всі інші. Як тільки це змінилося, вузьке місце для успіху програми перейшло від можливості взагалі працювати до запускувсе більше і більше блискучих речей , і ось де ми зараз.

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

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

Однією з причин є те, що дані, запаковані в додатках, є більшими, оскільки вони мають більш високу роздільну здатність та якість. Піктограма ще в часи Netscape мала максимум 32х32 пікселів, максимум 8-бітна глибина (можливо, лише 4,), тоді як зараз це, мабуть, щось на зразок 64х64 і в справжньому кольорі з прозорістю, тобто 32-бітовою глибиною. Це в 16 разів більше. А простір настільки дешевий, що люди часто навіть не турбуються перевіряти "стиснуту" опцію під час створення PNG.

Ще одна причина полягає в тому, що програми сьогодні несуть з собою приголомшливий обсяг даних, чого не мали старі програми. Сьогодні існують додатки, які постачаються разом із презентацією "Початок роботи" у відео .

Ще одна причина полягає в тому, що сьогодні мови програмування, як правило, поєднуються з багатим середовищем виконання, яке є досить великим, у розмірі 100 Мб кожна. Навіть якщо ви не використовуєте всі функції вашого середовища виконання, вам все одно доведеться пакувати всю програму за допомогою свого додатка.

Але головна причина полягає в тому, що сьогодні там є багато тонн і тонн бібліотек, які ми можемо використовувати у своїх програмах, і ми виробили культуру використання бібліотек, щоб уникнути постійного повторного винаходи колеса. Звичайно, щойно ви починаєте користуватися бібліотеками, з’являється кілька запитань, і ми виробили звичку давати на них найліберальніші відповіді:

• Чи варто включити ще одну бібліотеку, якщо вона буде використовуватися лише однією з моїх функцій? - так.

• Чи варто включити ще одну бібліотеку, якщо мені потрібен лише крихітний підмножина всього багатства функціональних можливостей, пропонованих цією бібліотекою? - так.

• Чи варто включити ще одну бібліотеку, якщо її включення врятує мене лише від 2-х днів роботи? - так.

• Чи варто включати кілька бібліотек, які служать більш-менш однаковою метою лише тому, що різні програмісти на моїй зарплаті вже знайомі з різними бібліотеками? - так.

  (Будь ласка, зауважте, що я просто дотримуюся цих тенденцій, я не висловлюю жодної заяви про те, чи згоден я чи не згоден з ними.)

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

Отже, підсумовуючи, чи програмне забезпечення поводиться як газ? Чи схильна вона займати весь доступний їй простір? У певному сенсі так, але не в якійсь тривожній мірі. Якщо ми подивимось на те, що займає найбільше місця на наших накопичувачах, для більшості з нас відповідь полягає в тому, що це далеко не програми, а засоби масової інформації, такі як фільми та музика . Програмне забезпечення не роздувається з тією ж швидкістю, що розширюється ємність зберігання, і навряд чи це колись з'явиться, тому в майбутньому додатки, ймовірно, становлять незначну частину доступного для користувачів місця для зберігання.

Окрім інших ансер, 10 років тому зазвичай існували окремі версії для локалізованих / інтернаціоналізованих версій. Зараз, як правило, у випадку випуску версії програми вбудована підтримка локалізації у кожній випущеній версії, що додає розмір програми.

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

Незважаючи на те, що графіка / зручність користування дійсно сприяють факторам, існує дуже багато цього, що складається з бібліотеки / надлишку зібраного коду.

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

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

Це правдоподібно, що програмне забезпечення повинно бути створене для того, щоб відповідати двом речам: користувачам та доступному обладнання. Програма підходить за своїм призначенням, якщо вона вчасно робить те, що користувач хоче, з обладнанням, що є у розпорядженні користувача. Ну так. Але в міру вдосконалення апаратних засобів у всіх виміряних розмірах збільшується кількість дискретних програм, які переходять від непридатних до придатних - дизайн-простір збільшується:

• Мови вищого рівня дозволяють висловлювати ідеї за менший код та час, ніж раніше. Ця знижена складність, навпаки, дає можливість висловлювати все більш складні ідеї.
• Об'єднання додатків із додатком може зробити його миттєвішим у використанні. Наприклад, це, мабуть, не задовго до того, як додатки для перевірки орфографії поставляться в комплекті з усіма відомими людству мовою - зрештою, це лише кілька гігабайт.
• Компенсація апаратних засобів дозволяє розробникам та користувачам більше вибирати, про який ресурс вони піклуються. Дивіться, наприклад, FLAC / OGG vs WAV, SVG vs PNG, індекси баз даних.
• Гуманні інтерфейси часто торгують тим, що раніше було б величезною кількістю обладнання для зручності використання. Анти-згладжування, висока роздільна здатність, швидке оновлення та перехід між тим, що становить дискретні панелі, - це все більш реалістичний, а отже, інтуїтивний та релейний досвід.

Це, безумовно, стосується програм Android. Чотири роки тому простий додаток займав приблизно 2-5 мегабайт місця. На сьогоднішній день простий додаток займає приблизно 10-20 мегабайт місця.

Чим більше місця, тим більше розмір програми.

Я думаю, що у випадку Android є дві основні причини:

• Google розширив рамки Android, додав багато нового функціоналу.

• Розробники більше не переймаються. Зображення включаються в набагато більшу роздільну здатність (звичайно, збільшується роздільна здатність екрана смартфона), сторонні бібліотеки бездумно включаються.

Багато цього зводиться до часу розробника та вартості цього часу. Ще в часи, коли Visual Basic вперше приїхав на сцену, він змагався з C / C ++, і великий стукіт був у тому, що ви могли написати "Hello World" в ANSI C для Windows, можливо, 15K. Проблема з VB полягала в тому, що у вас завжди був альбатрос бібліотеки часу виконання 300 Кб.

Тепер ви можете в 10 разів перевищити розмір вашої програми VB, і все одно це буде лише на кілька K більше, але в 10 разів більший розмір вашої програми C / C ++, і ви дивитесь на ще кілька МЕСЯТІВ.

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

З часом потреби користувача розвиваються і стають все більш вимогливими, тому постачальник / автори різних програмних програм змушені задовольняти ці потреби в ім'я конкуренції.

Але задоволення нової потреби означає часто додавати новий код. Новий код означає нові вразливості для усунення. Виправлення нових уразливостей може додати код або відкрити двері для нових вразливих місць.

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

Все це означає додавання нових шарів додатків (код), безпеки, а іноді і апаратних засобів.

Велика кількість розмірів відбувається з вбудованих у бібліотеках. У наші дні багато додатків побудовані за допомогою електрона, який поєднує величезну кількість із додатком. Якщо ви встановлюєте програми на Linux, їх зазвичай набагато менше, оскільки значна частина програми вже встановлена ​​через спільні бібліотеки, які також використовують інші програми.

Створюючи програмне забезпечення, якщо вам потрібна функція A, ви імпортуєте модуль A *. A * може вирішити A, але A * може вирішити проблеми більше, ніж A, а A * може бути великим. Усі великі модулі призводять до програмного забезпечення великого розміру.

Можливо, це не той самий випадок, але щось подібне: Якщо вам просто потрібно надрукувати "привіт світ" на консолі за допомогою Java, вам потрібно встановити JRE (> 60MB).

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

Я читав про якесь правило, що програми займуть усю наявну пам'ять незалежно від того, скільки вона є, але чому?

Це не зовсім так. Системи не звільнять споживану пам'ять, поки операційна система не опиниться під тиском пам'яті. Це підвищення продуктивності. Якщо ви переглядали сторінку з зображеннями, ви переходите. Ви можете перейти назад, тому потрібне зображення знову. Якщо операційна система має оперативну пам’ять, немає сенсу очищати пам'ять, поки ви не будете впевнені, що вона вам знову не знадобиться.

Одразу очищення пам’яті забирає користувальницькі цикли процесора та пропускну здатність пам’яті, коли вони, ймовірно, хочуть відобразити на екрані високовідчутливі веб-сторінки.

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

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

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

Але якщо ви подивитесь на це, ви можете виявити, що вони дійсно роблять більше речей. Наприклад, у веб-переглядачах працює модна графіка, є інструменти для розробників гладких, які не існували кілька років тому тощо. Вони також посилаються на багато бібліотек, використовуючи іноді лише невелику частину коду. Тому, хоча програми можуть збільшуватися в розмірах, щоб заповнити наявну пам'ять, деякі з них можуть бути наперед законними причинами.

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

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

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