Ask HN: заставит ли дефицит памяти писать экономный код? Ответ треда — усталое «нет»
На фоне скачка цен на DRAM кто-то спросил, возьмутся ли разработчики за более плотные алгоритмы. Ответ из 235 комментариев — почти единогласное «нет» по закону Беттериджа, и причина одна: память на клиенте — трагедия общин, и за её экономию никого не поощряют.
Повторяющийся диагноз: раздувание — архитектурное, а не алгоритмическое. Проблема в том, что в чат-приложение упаковывают Chromium, а не в выборе структуры данных.
Где оптимизация реально случится, по словам инженера из бигтеха: на сервере, где память — статья расходов, и в основном через «перестать делать глупости», а не через хитрые алгоритмы.
Вопрос и стена, в которую он упирается
Ask HN прост: при нынешнем скачке цен на память начнут ли программисты писать код экономнее — браться за «более продвинутые алгоритмы и структуры данных, которые тратят меньше памяти»? Тред из 235 комментариев отвечает почти единогласным «нет», и дело в стимулах, а не в способностях. Яснее всего объяснил основатель, который зарабатывает на десктопном софте:
«Память будут оптимизировать главным образом на серверной стороне, потому что память клиента — это трагедия общин. Если вы урезаете расход памяти, пока конкурент добавляет фичи, то сэкономленную вами память просто молча заберёт его приложение». — Mike Hearn, основатель Hydraulic
Где это случится, а где нет
Инженер изнутри крупной компании подтвердил серверное исключение — и проколол романтичную идею, будто речь про умные алгоритмы:
«На основной работе (одна из крупных техкомпаний) мы уже закладываем на следующий год большую цель: оптимизировать серверный код, чтобы снизить требования к памяти… На практике жду, что большинство оптимизаций придёт из „перестать делать глупости“, а не из „применить навороченные продвинутые алгоритмы“». — инженер из бигтеха, докладывающий изнутри планёрки
Диагноз, к которому тред возвращался снова и снова: расточительность вообще не в классе сложности вашего кода.
«Проблема не в алгоритмах и структурах данных, проблема в том, что чат-приложение собирают, упаковывая в него Chromium». — комментатор о том, где на самом деле живёт раздувание
И циничная однострочная сводка всей системы стимулов:
«Нет, если только вас не повышают за более эффективный код». — Xe Iaso, инженер-программист
Счёт приходит не на тот стол
Логика треда железная и слегка мрачная. Эффективность возникает там, где тот, кто может её обеспечить, сам и оплачивает счёт. На сервере память — расход оператора, поэтому дефицит превращается в строку бюджета и кому-то дают мандат её урезать. На ноутбуке пользователя память принадлежит пользователю, для вендора расход невидим, и любой сэкономленный байт тут же потратит следующее Electron-приложение в трее. Дефицит памяти даст более лёгкие бэкенды и ровно ноль более лёгких десктопных приложений: не потому что инженеры не умеют, а потому что никто не выкатывает тот квартал, где это сделали.
Получайте такие разборы каждый день
Главные истории Hacker News — на email, в Telegram или RSS.
Linux выпилил strncpy: шесть лет, 360 патчей и функция, которой 50 лет
Ядро убрало C-функцию, которая тихо плодила баги с 1970-х. В треде сошлись двое: тот, кто впервые увидел strncpy полвека назад, и создатель языка D. Оба согласны в одном: где бы она ни появлялась, там обнаруживался баг.