Верно, ConcurrentDictionary очень хорош для простых сценариев + не засоряет код. Но вот если ожидаются частые добавления (частые аллокации к памяти из-за захвата контекста) или комплексные условия, то своя реализация лока (с режимами read-write например) будет выйгрывать.
Благодарю. Было интересно посмотреть на аткульные "лимиты" структур. Но данные, вероятно, будут разными под разные платформы (win/linux/arm/x86/x64) в силу различий VM.
Возможно это как-то связано с сокращениями на почве поддержки Палестины
Верно, ConcurrentDictionary очень хорош для простых сценариев + не засоряет код. Но вот если ожидаются частые добавления (частые аллокации к памяти из-за захвата контекста) или комплексные условия, то своя реализация лока (с режимами read-write например) будет выйгрывать.
Стоило бы еще упомянуть о System.Threading.Channels, которые отлично подходят для реализации producer-consumer
Благодарю. Было интересно посмотреть на аткульные "лимиты" структур.
Но данные, вероятно, будут разными под разные платформы (win/linux/arm/x86/x64) в силу различий VM.
.NET 8 умеет AOT компиляцию под целевые системы (с вырезанием "лишних" зависимостей).
Не имею релевантного опыта на Go, но интересно было бы их сравнение performance/usability.