Memory Traffic: Що робити, якщо тормозить оператор new

Memory Traffic: Що робити, якщо тормозить оператор new
Прискорити код у 10 000 разів іноді простіше, ніж отримати скромні +45% продуктивності.

У цьому відео розповідаю реальну історію оптимізації парсингу тексту в IDE. Три місяці роботи команди, кеш усередині пайплайну, профілювання, боротьба з алокаціями та оператором `new` — і лише 18% приросту на першому етапі.

Розберемося:

- чому теоретичне прискорення майже ніколи не збігається з реальним;
- як маленькі алокації створюють великі проблеми;
- чому 20 000 заздалегідь створених масивів виявилися хорошою ідеєю;
- у якому випадку `LinkedList` може бути кращим за `List`;
- як профайлер допоміг довести загальне прискорення до 45%.

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

А які неочевидні оптимізації траплялися у ваших проєктах? Діліться історіями в коментарях.

Підписуйтеся на Dev Jungles — тут говоримо про .NET, архітектуру, продуктивність і реальну розробку без магії маркетингових цифр.

Підтримати канал можливо за допомогою:
- Прямим переказом на карту монобанку
Dev Jungles YouTube Channel Fund

Номер карти банки:
Приховано: реквізити

- Або криптою:
BTC - Приховано: гаманець
ETH - Приховано: гаманець

USDT on ERC20 - Приховано: гаманець
USDT on TRC20 - Приховано: гаманець

LTC - LN3CkrnvZLZTXDUhqTy1gUKMVpLjEPA4G2

DOGE - DPwon439jf3axVSBwyuXso6z7CivuJF655
AAVE - Приховано: гаманець
Waves - Приховано: гаманець