Comments 4
Это просто шикарно!
С выходом C# 10 компилятор научился разбирать
$"строка"не напрямую вstring, а в handler: структуру, которая получает куски литералов и плейсхолдеры. Базовый –DefaultInterpolatedStringHandler.
У меня тоже была проблема с аллокациями в логах, и решал я её как-то так:
string text = $”Значение равно {value}%”;
mew text = (“Значение равно “, value , “%”);
//mew - значимый тип, который хранит фрагменты строки
//в их исходном виде (строки как строки,
//числа — как числа, bool как bool).
//Первые 48 фрагментов хранятся на стеке,
//далее уже идёт аллокация в куче.Но синтаксис кортежей это просто боль после $"значение:{value}". Теперь же, как я понял, можно к этой штуке прикрутить нормальный синтаксис конкатенации строк.
Вообще странно, что они не сделали сам тип string как-нибудь так, чтобы если строка короткая, то она пыталась бы храниться на стеке. Смысла дёргать кучу из-за текста в 10 букв, имхо, нет.
Вообще странно, что они не сделали сам тип string как-нибудь так, чтобы если строка короткая, то она пыталась бы храниться на стеке.
Есть подвижки в .NET 10.0 в эту сторону, но чтобы объект можно было аллоцировать на стеке, джит должен сам себе доказать что он никаким образом не убегает в хип
Эфемерные аллокации типа таких не нагружают гц, люди часто с ними борятся непонятно зачем. Гораздо хуже аллокации при которых создаются Gen2 -> Gen0 линки
Просто возьмите эту прекрасную библиотеку https://github.com/stbychkov/AutoLoggerMessage
И пишите логи как писали) библиотека сама все сделает по красоте
Спасибо за статью! Странно что подобного хендлера нет из коробки...
InterpolatedStringHandler: избавляемся от лишних аллокаций в логах