> I’m curious in what industry you’re utilizing those features.
Performance engineering for CDN systems!
> I imagine you must be using mostly your own code since much of nuget contains things that don’t take performance as a first priority.
This was my assumption too. While "much of nuget" trend continues to hold, there are actually quite a few performance-oritned libraries nowadays.
Bindings and binging generators (that are near-zero-cost), managed allocator implementations, high-performance parsers and serializers (which completely wipe the floor with alternatives written in flimsy languages like Go), higher-level APIs for graphics libraries (DX12, Vulkan, ...), high-performance primitive libraries, game engines, and more.
You are correct to point out that performance-sensitive code tends to avoid standard library containers and certain APIs, but CoreLib itself has been exposing quite a few APIs (like ArrayPool) and tends to practically always offer Span<T>-based method overloads so the data can reside in any memory if it needs so (stackalloc, array pool, unmanaged, or anything in between).
Sure, if you have a hot path you will probably avoid using List<T> and StringBuilder in favor of something less allocation-heavy, but it's generally the Unity land that is subjected to pain of fighting with every allocation rather than .NET itself.
Performance engineering for CDN systems!
> I imagine you must be using mostly your own code since much of nuget contains things that don’t take performance as a first priority.
This was my assumption too. While "much of nuget" trend continues to hold, there are actually quite a few performance-oritned libraries nowadays.
Bindings and binging generators (that are near-zero-cost), managed allocator implementations, high-performance parsers and serializers (which completely wipe the floor with alternatives written in flimsy languages like Go), higher-level APIs for graphics libraries (DX12, Vulkan, ...), high-performance primitive libraries, game engines, and more.
You are correct to point out that performance-sensitive code tends to avoid standard library containers and certain APIs, but CoreLib itself has been exposing quite a few APIs (like ArrayPool) and tends to practically always offer Span<T>-based method overloads so the data can reside in any memory if it needs so (stackalloc, array pool, unmanaged, or anything in between).
Sure, if you have a hot path you will probably avoid using List<T> and StringBuilder in favor of something less allocation-heavy, but it's generally the Unity land that is subjected to pain of fighting with every allocation rather than .NET itself.