Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
01.08.2025
Асимптотична оптимізація
Роб Пайк казав, що оптимізувати наперед не варто. Та в цілому, я згодний з цим! Оптимізація майже завжди ускладнює код або загрожує багами, отже, писати “заздалегідь оптимізований” код — погана звичка.
Втім, чи значить це, що можна взагалі не піклуватися про ефективність програми? Та взагалі-то не дуже… Особливо коли у вас є продакшн, на якому даних на кілька порядків більше ніж все, що можна побачити в себе локально чи на стейджингу.
Для того є просте правило. Поки пишеш код, потрібно мати на увазі та враховувати, скільки циклів та рекурсивних викликів він робить. Бо це впливає на асимптотичну оцінку складності — чи буде програма O(N), O(N²) тощо. Від цієї оцінки дійсно залежить, чи буде наша програма літати або лежати.
Звісно, нюанс перший в тому, що більшість складності прихована в коді, часто чужому. Тому досвідчений програміст памʼятатиме, що пошук в невідсортованому масиві має складність O(N), сортування - O(NlogN) тощо. А ще складність може сидіти в базі даних.
Другий різновид оптимізації — оптимізація множника — це коли ми заміняємо код на трішки більш ефективний, без зміни асимптотичної оцінки. Наприклад, прибираємо виклик функції. Або використовуємо особливий тип змінної. Або інший тип циклу. Все це не приносить категоричних змін: повільна програма залишиться повільною, швидка — швидкою.
Тому я б не дуже переймався таємними знаннями на кшталт “якщо переставити ці два аргументи місцями, операція буде на 20% швидше”. Та тим паче не поспішав впроваджувати в код. Краще вивчити О-складність — спочатку базових алгоритмів, а потім на конкретних структурах даних у вашій мові та СУБД.
Та якщо даних мало — все це не важливо. А їх майже завжди мало. То на видачах з 10-100 елементів взагалі можна не забивати собі голову. Першим пріоритетом була, є, та завжди залишається зрозумілість алгоритму для людей.