Вы написали struct ради zero-allocation, прошли code review — а в проде Gen0-коллекции всё равно идут косяком. Самая дорогая аллокация та, которой нет в исходниках: компилятор молча упаковывает ваш value-тип в кучу там, где вы этого не просили.

Разбираю, где скрытый боксинг живёт и на .NET 10 (интерфейс на struct, foreach по IEnumerable, ValueType.Equals, params object[], замыкания), а где рантайм его уже вырезал — и почему слепо чинить HasFlag по гайдам 2015 года вредно. Два прод-кейса, шпаргалка-таблица, бенчмарк на BenchmarkDotNet и охота на box через DOTNET_JitDisasm и dotnet-gcdump.

В .NET 9 Dynamic PGO включён по умолчанию, и это не просто “ещё +10–15% перформанса в релиз-ноутах”. Это новая среда обитания вашего кода. Один и тот же бинарник на одной и той же машине может работать в 3–5 раз медленнее или быстрее в зависимости от того, какие данные он увидел в первые секунды жизни.

Я называю это эффектом JIT-дрифта: метод “застывает” под профиль ранней нагрузки и потом не успевает перестроиться под реальный продакшен. Ниже - минимальный воспроизводимый пример на 20 строк, разбор того, что именно RyuJIT решает за вас, и чек-лист, как с этим жить на проде.

TL;DR. Один «безобидный» foo.GetAsync().Result в middleware способен превратить ASP.NET Core, державший 50k RPS с p99 = 40 мс, в сервис с 12k RPS и p99 = 4 с — при CPU 8 %.

Виноват не сам blocking call, а hill-climbing — фидбэк-луп в ThreadPool, в недрах которого живёт дискретное преобразование Фурье. Разбираем по исходникам CoreCLR, почему это вообще возможно, воспроизводим эффект на ~80 строках кода и разбираемся, почему SetMinThreads — не решение, а анестезия.