Перемещение и обработка данных — одна из самых частых задач в Web API. Пока объёмы невелики — всё просто. Но когда входящие файлы или JSON становятся большими (десятки МБ и более), прямые аллокации приводят к LOH, дефрагментации памяти и падению производительности.
Доклад показывает, как одну и ту же задачу можно решить тремя подходами — от Junior до архитектора:
Junior-style: читаем всё в память, получаем LOH и GC-паузы
Middle-style: работаем чанками, применяем буферизацию, ограничиваем аллокации
Senior-style: проектируем API через Span, Memory, IBufferWriter, строим zero-alloc поток
На живом примере — передача большого JSON из PostgreSQL клиенту — сравниваем RPS и latency при:
полном чтении через ReadToEndAsync()
потоковой отдаче через SequentialAccess + GetStream
zero-alloc pipeline
Демонстрируем:
когда ArrayPool и RecyclableMemoryStream дают выигрыш, а когда стоит написать свой буфер
как замерить эффект от оптимизаций через BenchmarkDotNet, dotnet-trace и EventCounters
чеклист: «что проверить, чтобы большие данные не съели всю память»
