6 ms·

Safe zero-copy operations in C#

221 points by sedatk 1y ago

bob1029 1y ago
> Spans and slice-like structures in are the future of safe memory operations in modern programming languages. Embrace them. I've been using Span<T> very aggressively and it makes a massive difference in cases where you need logical views into the same physical memory. All of my code has been rewritten to operate in terms of spans instead of arrays where possible. It can be easy to overlook ToArray() or (more likely) code that implies its use in a large codebase. Even small, occasional allocations are all it takes to move your working set out of the happy place and get the GC cranking. The difference in performance can be unreasonable in some cases. You can even do things like: var arena = stackalloc byte[1024]; var segment0 = arena.Slice(10); var segment1 = arena.Slice(10, 200); ... The above will incur no GC pressure/activity at all. Everything happens on the stack.
- rurban 1y ago
  [flagged]
  - davidatbu 1y ago
    Super interesting! Was this C# or something? is there a write-up/mini-blogpost about this somewhere?
  - adrian_b 1y ago
    That looks more like the effect of a bad compiler. On most modern CPUs, including Intel/AMD & ARM-based, memory accesses with relative-addressing to the stack have at least the same performance if not much better performance than memory accesses through pointers to the heap. The stack is also normally cached automatically by the memory prefetcher. So whichever was the cause of your performance increase was not an inefficiency of the stack accesses, but some other difference in the code generated by the compiler. Such an unexpected and big performance difference could normally be caused only by a compiler bug. A special case when variables allocated in the stack can lead to low performance is when a huge amount of variables are allocated or many arrays are allocated, and then they are only sparsely used and the initial stack is much smaller. Then any new allocation of an array or big bunch of variables may exceed the stack size, which will cause a page fault, so that the operating system will grow the stack by one memory page. This kind of transparent memory allocation by page faults can be much slower than the explicit memory allocation done by malloc or new. This is why big arrays should normally be allocated either statically or in the heap.
    - osigurdson 1y ago
      What they are saying is the stackalloc approach causes no GC pressure. You can run that in a tight / infinite loop with essentially no downside. Using a regular heap allocated array in the same situation will hammer the GC. C# doesn't do escape analysis and automatically put things on the stack like (for example) Go does. However the stack size is limited in C# so I wouldn't suggest going too crazy with stackalloc and deep stacks / recursion. You don't want a stack overflow!
      - ygra 1y ago
        > C# doesn't do escape analysis and automatically put things on the stack There has been work ongoing in this direction since .NET 9 at least, but the effect is very limited currently. The following code however, has no allocations at runtime, despite having an object creation in the code: https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3utmbjgJYB2w2AYgPaMAUAlMaedwG5gBO2MNgC82agFMA7thrAA2gHYAugG4u3MnEVCAdABkJ1AObAAFurTcAvumtA= https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3ut...
      - Izikiel43 1y ago
        > C# doesn't do escape analysis In net9 they started on that, and on net10 they have improved it, you can check the performance blogpost by Stephen toub for net10 for more info
  - uecker 1y ago
    I do not understand this comment. A stack access should never be more expensive than access to malloced data. This is easy to see: Malloc gives you a pointer. An address computation to find a variable on the stack also gives you a pointer but is much cheaper than malloc. If the compiler recomputes the address to a stack variable then this must be because it is deemed cheaper than wasting a register to cache the pointer. Nowadays compilers can transform malloc to stack allocations variables in certain cases.
  - nlitened 1y ago
    > Just a few days ago I changed stack access to heap access in a larger generated perfect hash and got 100x better performance Link me the code so that I can show what you did wrong
    - rurban 1y ago
      https://github.com/rurban/cmph/commit/4bb99882cc21fd44e8660294bb329dee1840df92 https://github.com/rurban/cmph/commit/4bb99882cc21fd44e86602... I did not nothing wrong :) And I remember better now. I changed stack access to immediate global access to const arrays. And insane was the compilation time, not so much the runtime. -O2 timed out, and if it compiled it was 10x slower run-time. Now compilation is immediate. This compiles large perfect hashes to C code. Like gperf, just better and for huge arrays.
      - nlitened 1y ago
        Thank you for linking. In this case, as I understand, you switched from a local array which is re-initialized with values upon each function invocation to a global array that is pre-initialized before even the program starts. So my understanding is you're measuring the speed between repeated re-initialization of your local array and no initialization at all — not between "relative" stack access and "absolute" heap or global memory access. As I understand, to do it the way you wanted initially, your local array must be `static const` instead of just const (so that there's a single copy of it, essentially making it a global variable as well). To be honest, I am not sure why C compiler doesn't optimize it this way automatically, likely I don't know C spec well enough to know the reasons.
  - whizzter 1y ago
    Not trying to mock here, but did you program assembly in the 80s/90s and/or look at compilers involved with CPU's of comparable complexity to the 68000 series or older? Yes, relative addressing on older machines like that does hurt a ton (I was coding a jam-game of the GameBoy recently and had to re-orient some of my code away from stack-usage since I've gotten a tad "lazy" over the years and didn't care to program 100% assembly). On modern machines (since circa Pentium generation CPU's) that can do one cycle-multiplications memory-offset accesses are often irrelevant for the performance of access operations. More importantly, at about 500mhz-1ghz the sheer latency of main-memory accesses vs cached accesses will start to become your main worry since cache-misses start to approach _hundreds of cycles_ (this is why we have the entire data-oriented-design philosophy growing), while on the other hand the modern CPU's can pipeline many instructions to even make the impact of bounds checks more or less insignificant compared cache misses.
- CrimsonCape 1y ago
  Why can't I stackalloc an array of references? Shouldn't it be as simple as stackalloc nint[5]; ? Somebody decided that "safety" included rejecting obvious concepts like this.
progmetaldev 1y ago
I truly appreciate articles like this. I am using the Umbraco CMS, and have written code to use lower than the recommended requirements to keep the entire system running. While I don't see a use for using a Span<T> yet, I could definitely see it being useful for a website with an enormous amount of content. I am currently looking into making use of "public readonly record struct" for the models that I create for my views. Of course, I need to performance profile the code versus using standard classes with readonly properties where appropriate, but since most of my code is short-lived for pulling from the CMS to hydrate classes for the views, I'm not sure how much of a benefit I will get. Luckily I'm in a position to work on squeezing as much performance as possible between major projects. I'm curious if anyone has found any serious performance benefit from using a Span<T> or a "public readonly record struct" in a .NET CMS, where the pages are usually fire and forget? I have spent years (since 2013) trying to squeeze every ounce of performance from the code, as I work with quite a few smaller businesses, and even the rest of my team are starting to look into Wix or Squarespace, since it doesn't require a "me" to be involved to get a site up and running. To my credit and/or surprise, I haven't dealt with a breach to my knowledge, and I read logs and am constantly reviewing code as it is my passion (at least working within the confines of the Umbraco CMS, although it isn't my only place of knowledge). I used to work with PHP and CodeIgniter pre-2013 (then Kohana a bit while making the jump from PHP to .NET). I enjoy C#, and feel like I am able to gain quite a bit of performance from it, but if anyone has any ideas for me on how to create even more value from this, I would be extremely interested.
- MarkSweep 1y ago
  > I'm curious if anyone has found any serious performance benefit from using a Span<T> or a "public readonly record struct" in a .NET CMS This response is not directly answering that "in a .NET CMS" part of your question. I'm just trying to say how to think about when to worry about optimizations. These sorts of micro optimizations are best considered when your are trying to solve a particular performance problem, particularly when you are dealing with a site that is not getting a lot of hits. I've experienced using small business ecommerce websites where each page load takes 5 seconds and given up trying to buy something. In that case profiling the site and figuring out the problem is very worth while. When you have a site getting a lot of hits, these sorts of performance optimizations can help you save cost. If your service takes 100 servers to run and you can find some performance tweaks to get down to 75 server, that may be worth the engineering effort. My recommendation is to use a profiler of some type. Either on your application in aggregate to identify hot spots in in search of the source of a particular performance problem. Once you identify a hot spot, construct a micro benchmark of the problem in BenchmarkDotNet and try to use tools like Span<T> to fix the problem.
Freedom2 1y ago
I recall a specific project involving a network appliance that generated large log streams. Our bottleneck was the log parser, which was aggressively using string.Substring() to isolate fields. This approach continuously allocated new string objects on the heap, which led to excessive pressure on the GC. The transition to using ReadOnlySpan<char> immediately addressed the allocation issue. We were able to represent slices of the incoming buffer without any heap allocations and the parser logic was simplified significantly.
hahn-kev 1y ago
I'm a C# dev main and love spans. I understand it's not in the same realm as Rust, but how comparable is this to some of the power that Rust gives you?
- afdbcreid 1y ago
  It's a taste. C# allows the more common patterns, but Rust allows much more. For example, Rust allows the equivalent of storing `Span<T>` (called slice in Rust) everywhere (including on the heap, although this is rare).
  - Rohansi 1y ago
    The restriction in C# comes from its ability to reference stack allocated memory. I'm not familiar with Rust but it probably figures it out based on the lifetime of T.
    - Measter 1y ago
      It's not the lifetime of T, but the lifetime of whatever is storing T.
  - sedatk 1y ago
    C# has a separate heap storable span equivalent called Memory<T>.
    - afdbcreid 1y ago
      AFAIK it's less efficient though.
      - sedatk 1y ago
        Yes, but it can still beat copying.
- whizzter 1y ago
  I think the main differentiator is this: C# is GC'd, the system will protect memory in use and while it can allow things like Span<>, Memory<>,etc there are some constraints due to sloppy lifetime reasoning but in general "easy" usage since you do not need to care about lifetime. Rust has lifetime semantics built down to the core of the language, the compiler will know much better about what's safe but also forbid you early from things that are safe but not provable (they're improving the checkers based on experience though), due to it's knowledge it will be better at handling allocations more exactly. Personally as someone with an assembly, C,C++,etc background, while I see the allure of Rust and do see it as a plus if less experienced devs that really need perf go for Rust for critical components, and thinking I'm going to try to do some project in Rust... I've so far not seen a project where the slight performance improvement of Rust will outweight the "productivity" gain from being able to do a bit "sloppy" connections that C# allows for.
smilekzs 1y ago
Anecdote: 9 years ago I was at MSFT. Hands forced by long GC pauses, eventually many teams turned to hand-rolling their flavor of string_view in C#. It was literally xkcd.com/927 back then when you tried to interface with some other team's packages and each side has the same but different string_view classes. Glad to see that finally enjoying language and stdlib support.
- ZeroConcerns 1y ago
  (ReadOnly)Span<T> has been available for 8 years now, and even before that, in the legacy Framework, there were common readonly-ref string slicers.
  - pjmlp 1y ago
    ArraySegment for example.
  - Izikiel43 1y ago
    You are assuming most devs know about this. I do check the standard library for things that sound like they should be there as their common enough. My experience tells me this approach is not as common as you would expect, same for C# in msft, I don’t know how many people using framework knew about array segment.
buybackoff 1y ago
For working with arrays elements without bound checks, this is the modern alternative to pointers, without object pinning for GC and "unsafe" keyword: MemoryMarshal. GetArrayDataReference<T>(T[]). This is still totally unsafe, but is "modern safer unsafe" that works with `ref`s and makes friends with System.Runtime.CompileServices.Unfafe. Funny point: the verbosity of this method and SRCS.Unsafe ones make them look slower vs pointers at subconscious level for me, but they are as fast if not faster to juggle with knifes in C#. The `fixed` keyword is mostly for fast transient pinning of data. Raw pointers from `fixed` remain handy in some cases, e.g. for alignment when working with AVX, but even this can be done with `ref`s, which can reference an already pinned array from Pinned Object Heap or native memory. Most APIs accept `ref`s and GC continues tracking underlying objects. See the subtle difference here for common misuse of fixed to get array data pointer: https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3utmbjgK4B2EYAZgKa4As2AYpMABQCW1wbBF4AvRgEpipcjIBuYAE7ZFSgLzZqjAO7Z+wANrCxAXWwBuaTLL1eAD0YATPgIBU2AA7A1yhQskB6f2wAZTAoZkhsAFlGKAB7BQBPKMUIAAswABsAOgBxRmAAQV8wRIARMGAwACVGJgVGagBjZksrIgBfbDaOtrasbBo6JlYQzLitZ0EjCSk0K3J5JRVsdU0dPUNRRlMLeYXsG3snPTdPbwAyFX0ABmMAoODgXkzM7AAhfEdsYDjsAHMCj80sx3HE9IwFG0ZJ1uvsyL00B0gA= https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3ut... Spans are great, but sometimes raw `ref`s are a better fit for a task, to get the last bits of performance.
- bengarney 1y ago
  I increasingly wonder if writing and binding performance critical things in C/C++ would be less overall effort. Performant zero-alloc C# vs C/C++ is backdoor magic vs first class language support. Boxing gloves vs. surgical gloves. C# _can_ do this! But I face many abstractions: special perf APIs, C#, IL, asm. Outcomes will vary with language version, runtime version, platform, IL2CPP/Burst/Mono/dotnet. But C/C++ has one layer of abstraction (the compiler), and it's locked in once I compile it. I want to do the thing as exactly and consistently as possible in the simplest way possible! A build environment that compiles .cpp alongside .cs (no automatic bindings, just compilation) would be so nice for this. ---- Example of what I mean regarding abstractions: void addBatch(int *a, int *b, int count) { for(int i=0; i<count; i++) a[i] += b[i]; } versus: [MethodImpl(MethodImplOptions.AggressiveOptimization)] public static void AddBatch(int[] a, int[] b, int count) { ref int ra = ref MemoryMarshal.GetArrayDataReference(a); ref int rb = ref MemoryMarshal.GetArrayDataReference(b); for (nint i = 0, n = (nint)count; i < n; i++) Unsafe.Add(ref ra, i) += Unsafe.Add(ref rb, i); } (This is obviously a contrived example, my point is to show the kinds of idioms at play.)
uecker 1y ago
Also works in C: https://uecker.codeberg.page/2025-07-02.html https://uecker.codeberg.page/2025-07-02.html
- aw1621107 1y ago
  I don't think that's quite a 1-to-1 match for what's described in the article. Both C#'s Span<T> and your span type are type- and bounds-safe, but the former has additional restrictions placed on its usage thanks to the `ref` keyword that guarantee that it will be free of lifetime errors as well without needing to involve the runtime.
  - uecker 1y ago
    True, that part is different and not safe in C. Lifetime is something that will need new language extensions / annotations.
pjmlp 1y ago
This is a good example to learn how to use the tools a programming language offers, just saying a programing language has a GC thus bad is meaningless, without understanding what is actually available. Regarding, > Spans and slice-like structures in are the future of safe memory operations in modern programming languages. It is sad how long stuff takes to reach mainstream technology, in Oberon the equivalent declaration to partition would be, PROCEDURE partition(span: ARRAY OF INTEGER): INTEGER And if the type is the special case of ARRAY OF BYTE (need to import SYSTEM for that), then any type representation can be mapped into a span of bytes. You will find similar capabilities in Cedar, Modula-2+, Modula-3, among several others. Modern safe memory langaguage are finally catching up with the 1990's research, pity it always takes this much for adoption of cool ideas. Having said this, I feel modern .NET has all the features that made me like Modula-3 back in the day, even if some are a bit convoluted like inline arrays in structs.
- whizzter 1y ago
  Even on the contrary, once you introduce GC usage into languages without direct support you're basically always running a substandard GC because so many advances(enabled by read/write barriers) aren't really available without language support. Then people go around shouting GC's are bad because they used them with a language that made them use some of the worst ones out there.
klabetron 1y ago
For the op, awesome article. Quick question: what’s the definition of your `swap(array, i, pivotIndex)` function? Am I missing something? Or just assumes it’s the standard set temp to a, set a to b, and set b to temp?
- sedatk 1y ago
  Thanks! I've had several iterations on the code samples while writing the article, swap() was just a remnant. You guessed it correct, it was supposed to be replaced with tuple swaps: "(a,b)=(b,a)". Now, done. :)
titzer 1y ago
This is why Virgil has support for ranges in the language, which are better than slices. They are value types that represent a subset of a larger array. They can also be off-heap, which allows a Range<byte> to safely refer to memory-mapped buffers. https://github.com/titzer/virgil/blob/master/doc/tutorial/Ranges.md https://github.com/titzer/virgil/blob/master/doc/tutorial/Ra...
- algorithmsRcool 1y ago
  Isn't Span<T> the exact same concept?
  - titzer 1y ago
    Conceptually they are almost identical, though Virgil has explicit source syntax for making a subrange. One important difference, according to [1] Span<T> can only live on the stack. There are no lifetime restrictions for Range<T> in Virgil. [1] https://learn.microsoft.com/en-us/archive/msdn-magazine/2018/january/csharp-all-about-span-exploring-a-new-net-mainstay https://learn.microsoft.com/en-us/archive/msdn-magazine/2018...
    - achandlerwhite 1y ago
      Memory<T> is the heap compatible version of Span<T> in C# for anyone curious.
rkagerer 1y ago
Array element accesses are bounds-checked in C# for safety. But, that means that there's performance impact... Why don't we have hardware support for this yet? (i.e. CPU instructions that are bounds-aware?) Edit: Do we? https://stackoverflow.com/questions/40752436/do-any-cpus-have-hardware-support-for-bounds-checking https://stackoverflow.com/questions/40752436/do-any-cpus-hav...
mwsherman 1y ago
I move between Go and C#. I wrote a zero-allocation package in Go [1] and then ported to C# — and the allocations exploded! I had forgotten, or perhaps never realized, that substrings in C# allocate. The solution was Spans. Notably, it caused me to realize that Go had “spans” designed in from the start. [1] https://github.com/clipperhouse/uax29 https://github.com/clipperhouse/uax29
- neonsunset 1y ago
  No, slices in Go are more akin to ArraySegment but with resizing/copy-on-append. It does not have the same `byref` mechanism .NET supports, which can reference arbitrary memory (GC-owned or otherwise) in a unified way as a single (special) pointer type.
  - int_19h 1y ago
    Go pointers can point at the stack or inside objects just fine, they are exactly as expressive as C# unsafe pointers (i.e. more expressive than `ref`). What Go can't do is create a single-element slice out of a variable or pointer to it. But that just means code duplication if you need to cover both cases, not that it's not expressible at all.
    - kbolino 1y ago
      > What Go can't do is create a single-element slice out of a variable or pointer to it. var x int s := unsafe.Slice(&x, 1) fmt.Println(&x == &s[0]) // Output: true
      - int_19h 1y ago
        Good catch! That takes care of the unsafe pointer case, but not the safe ref case. There's no reason for this to be unsafe - you're asking for a 1-element slice, and the compiler knows that the variable is always going to be there as long as the reference exists. In C#, `Span<T>` has a (safe) constructor from `ref T`.
  - 1y ago

221 points by sedatk 1y ago

> Spans and slice-like structures in are the future of safe memory operations in modern programming languages. Embrace them. I've been using Span<T> very aggressively and it makes a massive difference in cases where you need logical views into the same physical memory. All of my code has been rewritten to operate in terms of spans instead of arrays where possible. It can be easy to overlook ToArray() or (more likely) code that implies its use in a large codebase. Even small, occasional allocations are all it takes to move your working set out of the happy place and get the GC cranking. The difference in performance can be unreasonable in some cases. You can even do things like: var arena = stackalloc byte[1024]; var segment0 = arena.Slice(10); var segment1 = arena.Slice(10, 200); ... The above will incur no GC pressure/activity at all. Everything happens on the stack.

rurban 1y ago
[flagged]
- davidatbu 1y ago
  Super interesting! Was this C# or something? is there a write-up/mini-blogpost about this somewhere?
- adrian_b 1y ago
  That looks more like the effect of a bad compiler. On most modern CPUs, including Intel/AMD & ARM-based, memory accesses with relative-addressing to the stack have at least the same performance if not much better performance than memory accesses through pointers to the heap. The stack is also normally cached automatically by the memory prefetcher. So whichever was the cause of your performance increase was not an inefficiency of the stack accesses, but some other difference in the code generated by the compiler. Such an unexpected and big performance difference could normally be caused only by a compiler bug. A special case when variables allocated in the stack can lead to low performance is when a huge amount of variables are allocated or many arrays are allocated, and then they are only sparsely used and the initial stack is much smaller. Then any new allocation of an array or big bunch of variables may exceed the stack size, which will cause a page fault, so that the operating system will grow the stack by one memory page. This kind of transparent memory allocation by page faults can be much slower than the explicit memory allocation done by malloc or new. This is why big arrays should normally be allocated either statically or in the heap.
  - osigurdson 1y ago
    What they are saying is the stackalloc approach causes no GC pressure. You can run that in a tight / infinite loop with essentially no downside. Using a regular heap allocated array in the same situation will hammer the GC. C# doesn't do escape analysis and automatically put things on the stack like (for example) Go does. However the stack size is limited in C# so I wouldn't suggest going too crazy with stackalloc and deep stacks / recursion. You don't want a stack overflow!
    - ygra 1y ago
      > C# doesn't do escape analysis and automatically put things on the stack There has been work ongoing in this direction since .NET 9 at least, but the effect is very limited currently. The following code however, has no allocations at runtime, despite having an object creation in the code: https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3utmbjgJYB2w2AYgPaMAUAlMaedwG5gBO2MNgC82agFMA7thrAA2gHYAugG4u3MnEVCAdABkJ1AObAAFurTcAvumtA= https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3ut...
    - Izikiel43 1y ago
      > C# doesn't do escape analysis In net9 they started on that, and on net10 they have improved it, you can check the performance blogpost by Stephen toub for net10 for more info
- uecker 1y ago
  I do not understand this comment. A stack access should never be more expensive than access to malloced data. This is easy to see: Malloc gives you a pointer. An address computation to find a variable on the stack also gives you a pointer but is much cheaper than malloc. If the compiler recomputes the address to a stack variable then this must be because it is deemed cheaper than wasting a register to cache the pointer. Nowadays compilers can transform malloc to stack allocations variables in certain cases.
- nlitened 1y ago
  > Just a few days ago I changed stack access to heap access in a larger generated perfect hash and got 100x better performance Link me the code so that I can show what you did wrong
  - rurban 1y ago
    https://github.com/rurban/cmph/commit/4bb99882cc21fd44e8660294bb329dee1840df92 https://github.com/rurban/cmph/commit/4bb99882cc21fd44e86602... I did not nothing wrong :) And I remember better now. I changed stack access to immediate global access to const arrays. And insane was the compilation time, not so much the runtime. -O2 timed out, and if it compiled it was 10x slower run-time. Now compilation is immediate. This compiles large perfect hashes to C code. Like gperf, just better and for huge arrays.
    - nlitened 1y ago
      Thank you for linking. In this case, as I understand, you switched from a local array which is re-initialized with values upon each function invocation to a global array that is pre-initialized before even the program starts. So my understanding is you're measuring the speed between repeated re-initialization of your local array and no initialization at all — not between "relative" stack access and "absolute" heap or global memory access. As I understand, to do it the way you wanted initially, your local array must be `static const` instead of just const (so that there's a single copy of it, essentially making it a global variable as well). To be honest, I am not sure why C compiler doesn't optimize it this way automatically, likely I don't know C spec well enough to know the reasons.
- whizzter 1y ago
  Not trying to mock here, but did you program assembly in the 80s/90s and/or look at compilers involved with CPU's of comparable complexity to the 68000 series or older? Yes, relative addressing on older machines like that does hurt a ton (I was coding a jam-game of the GameBoy recently and had to re-orient some of my code away from stack-usage since I've gotten a tad "lazy" over the years and didn't care to program 100% assembly). On modern machines (since circa Pentium generation CPU's) that can do one cycle-multiplications memory-offset accesses are often irrelevant for the performance of access operations. More importantly, at about 500mhz-1ghz the sheer latency of main-memory accesses vs cached accesses will start to become your main worry since cache-misses start to approach _hundreds of cycles_ (this is why we have the entire data-oriented-design philosophy growing), while on the other hand the modern CPU's can pipeline many instructions to even make the impact of bounds checks more or less insignificant compared cache misses.
CrimsonCape 1y ago
Why can't I stackalloc an array of references? Shouldn't it be as simple as stackalloc nint[5]; ? Somebody decided that "safety" included rejecting obvious concepts like this.

progmetaldev 1y ago

I truly appreciate articles like this. I am using the Umbraco CMS, and have written code to use lower than the recommended requirements to keep the entire system running. While I don't see a use for using a Span<T> yet, I could definitely see it being useful for a website with an enormous amount of content. I am currently looking into making use of "public readonly record struct" for the models that I create for my views. Of course, I need to performance profile the code versus using standard classes with readonly properties where appropriate, but since most of my code is short-lived for pulling from the CMS to hydrate classes for the views, I'm not sure how much of a benefit I will get. Luckily I'm in a position to work on squeezing as much performance as possible between major projects. I'm curious if anyone has found any serious performance benefit from using a Span<T> or a "public readonly record struct" in a .NET CMS, where the pages are usually fire and forget? I have spent years (since 2013) trying to squeeze every ounce of performance from the code, as I work with quite a few smaller businesses, and even the rest of my team are starting to look into Wix or Squarespace, since it doesn't require a "me" to be involved to get a site up and running. To my credit and/or surprise, I haven't dealt with a breach to my knowledge, and I read logs and am constantly reviewing code as it is my passion (at least working within the confines of the Umbraco CMS, although it isn't my only place of knowledge). I used to work with PHP and CodeIgniter pre-2013 (then Kohana a bit while making the jump from PHP to .NET). I enjoy C#, and feel like I am able to gain quite a bit of performance from it, but if anyone has any ideas for me on how to create even more value from this, I would be extremely interested.

MarkSweep 1y ago
> I'm curious if anyone has found any serious performance benefit from using a Span<T> or a "public readonly record struct" in a .NET CMS This response is not directly answering that "in a .NET CMS" part of your question. I'm just trying to say how to think about when to worry about optimizations. These sorts of micro optimizations are best considered when your are trying to solve a particular performance problem, particularly when you are dealing with a site that is not getting a lot of hits. I've experienced using small business ecommerce websites where each page load takes 5 seconds and given up trying to buy something. In that case profiling the site and figuring out the problem is very worth while. When you have a site getting a lot of hits, these sorts of performance optimizations can help you save cost. If your service takes 100 servers to run and you can find some performance tweaks to get down to 75 server, that may be worth the engineering effort. My recommendation is to use a profiler of some type. Either on your application in aggregate to identify hot spots in in search of the source of a particular performance problem. Once you identify a hot spot, construct a micro benchmark of the problem in BenchmarkDotNet and try to use tools like Span<T> to fix the problem.

Freedom2 1y ago

I recall a specific project involving a network appliance that generated large log streams. Our bottleneck was the log parser, which was aggressively using string.Substring() to isolate fields. This approach continuously allocated new string objects on the heap, which led to excessive pressure on the GC. The transition to using ReadOnlySpan<char> immediately addressed the allocation issue. We were able to represent slices of the incoming buffer without any heap allocations and the parser logic was simplified significantly.

hahn-kev 1y ago

I'm a C# dev main and love spans. I understand it's not in the same realm as Rust, but how comparable is this to some of the power that Rust gives you?

afdbcreid 1y ago
It's a taste. C# allows the more common patterns, but Rust allows much more. For example, Rust allows the equivalent of storing `Span<T>` (called slice in Rust) everywhere (including on the heap, although this is rare).
- Rohansi 1y ago
  The restriction in C# comes from its ability to reference stack allocated memory. I'm not familiar with Rust but it probably figures it out based on the lifetime of T.
  - Measter 1y ago
    It's not the lifetime of T, but the lifetime of whatever is storing T.
- sedatk 1y ago
  C# has a separate heap storable span equivalent called Memory<T>.
  - afdbcreid 1y ago
    AFAIK it's less efficient though.
    - sedatk 1y ago
      Yes, but it can still beat copying.
whizzter 1y ago
I think the main differentiator is this: C# is GC'd, the system will protect memory in use and while it can allow things like Span<>, Memory<>,etc there are some constraints due to sloppy lifetime reasoning but in general "easy" usage since you do not need to care about lifetime. Rust has lifetime semantics built down to the core of the language, the compiler will know much better about what's safe but also forbid you early from things that are safe but not provable (they're improving the checkers based on experience though), due to it's knowledge it will be better at handling allocations more exactly. Personally as someone with an assembly, C,C++,etc background, while I see the allure of Rust and do see it as a plus if less experienced devs that really need perf go for Rust for critical components, and thinking I'm going to try to do some project in Rust... I've so far not seen a project where the slight performance improvement of Rust will outweight the "productivity" gain from being able to do a bit "sloppy" connections that C# allows for.

smilekzs 1y ago

Anecdote: 9 years ago I was at MSFT. Hands forced by long GC pauses, eventually many teams turned to hand-rolling their flavor of string_view in C#. It was literally xkcd.com/927 back then when you tried to interface with some other team's packages and each side has the same but different string_view classes. Glad to see that finally enjoying language and stdlib support.

ZeroConcerns 1y ago
(ReadOnly)Span<T> has been available for 8 years now, and even before that, in the legacy Framework, there were common readonly-ref string slicers.
- pjmlp 1y ago
  ArraySegment for example.
- Izikiel43 1y ago
  You are assuming most devs know about this. I do check the standard library for things that sound like they should be there as their common enough. My experience tells me this approach is not as common as you would expect, same for C# in msft, I don’t know how many people using framework knew about array segment.

buybackoff 1y ago

For working with arrays elements without bound checks, this is the modern alternative to pointers, without object pinning for GC and "unsafe" keyword: MemoryMarshal. GetArrayDataReference<T>(T[]). This is still totally unsafe, but is "modern safer unsafe" that works with `ref`s and makes friends with System.Runtime.CompileServices.Unfafe. Funny point: the verbosity of this method and SRCS.Unsafe ones make them look slower vs pointers at subconscious level for me, but they are as fast if not faster to juggle with knifes in C#. The `fixed` keyword is mostly for fast transient pinning of data. Raw pointers from `fixed` remain handy in some cases, e.g. for alignment when working with AVX, but even this can be done with `ref`s, which can reference an already pinned array from Pinned Object Heap or native memory. Most APIs accept `ref`s and GC continues tracking underlying objects. See the subtle difference here for common misuse of fixed to get array data pointer: https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3utmbjgK4B2EYAZgKa4As2AYpMABQCW1wbBF4AvRgEpipcjIBuYAE7ZFSgLzZqjAO7Z+wANrCxAXWwBuaTLL1eAD0YATPgIBU2AA7A1yhQskB6f2wAZTAoZkhsAFlGKAB7BQBPKMUIAAswABsAOgBxRmAAQV8wRIARMGAwACVGJgVGagBjZksrIgBfbDaOtrasbBo6JlYQzLitZ0EjCSk0K3J5JRVsdU0dPUNRRlMLeYXsG3snPTdPbwAyFX0ABmMAoODgXkzM7AAhfEdsYDjsAHMCj80sx3HE9IwFG0ZJ1uvsyL00B0gA= https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3ut... Spans are great, but sometimes raw `ref`s are a better fit for a task, to get the last bits of performance.

bengarney 1y ago
I increasingly wonder if writing and binding performance critical things in C/C++ would be less overall effort. Performant zero-alloc C# vs C/C++ is backdoor magic vs first class language support. Boxing gloves vs. surgical gloves. C# _can_ do this! But I face many abstractions: special perf APIs, C#, IL, asm. Outcomes will vary with language version, runtime version, platform, IL2CPP/Burst/Mono/dotnet. But C/C++ has one layer of abstraction (the compiler), and it's locked in once I compile it. I want to do the thing as exactly and consistently as possible in the simplest way possible! A build environment that compiles .cpp alongside .cs (no automatic bindings, just compilation) would be so nice for this. ---- Example of what I mean regarding abstractions: void addBatch(int *a, int *b, int count) { for(int i=0; i<count; i++) a[i] += b[i]; } versus: [MethodImpl(MethodImplOptions.AggressiveOptimization)] public static void AddBatch(int[] a, int[] b, int count) { ref int ra = ref MemoryMarshal.GetArrayDataReference(a); ref int rb = ref MemoryMarshal.GetArrayDataReference(b); for (nint i = 0, n = (nint)count; i < n; i++) Unsafe.Add(ref ra, i) += Unsafe.Add(ref rb, i); } (This is obviously a contrived example, my point is to show the kinds of idioms at play.)

uecker 1y ago

Also works in C: https://uecker.codeberg.page/2025-07-02.html https://uecker.codeberg.page/2025-07-02.html

aw1621107 1y ago
I don't think that's quite a 1-to-1 match for what's described in the article. Both C#'s Span<T> and your span type are type- and bounds-safe, but the former has additional restrictions placed on its usage thanks to the `ref` keyword that guarantee that it will be free of lifetime errors as well without needing to involve the runtime.
- uecker 1y ago
  True, that part is different and not safe in C. Lifetime is something that will need new language extensions / annotations.

pjmlp 1y ago

This is a good example to learn how to use the tools a programming language offers, just saying a programing language has a GC thus bad is meaningless, without understanding what is actually available. Regarding, > Spans and slice-like structures in are the future of safe memory operations in modern programming languages. It is sad how long stuff takes to reach mainstream technology, in Oberon the equivalent declaration to partition would be, PROCEDURE partition(span: ARRAY OF INTEGER): INTEGER And if the type is the special case of ARRAY OF BYTE (need to import SYSTEM for that), then any type representation can be mapped into a span of bytes. You will find similar capabilities in Cedar, Modula-2+, Modula-3, among several others. Modern safe memory langaguage are finally catching up with the 1990's research, pity it always takes this much for adoption of cool ideas. Having said this, I feel modern .NET has all the features that made me like Modula-3 back in the day, even if some are a bit convoluted like inline arrays in structs.

whizzter 1y ago
Even on the contrary, once you introduce GC usage into languages without direct support you're basically always running a substandard GC because so many advances(enabled by read/write barriers) aren't really available without language support. Then people go around shouting GC's are bad because they used them with a language that made them use some of the worst ones out there.

klabetron 1y ago

For the op, awesome article. Quick question: what’s the definition of your `swap(array, i, pivotIndex)` function? Am I missing something? Or just assumes it’s the standard set temp to a, set a to b, and set b to temp?

sedatk 1y ago
Thanks! I've had several iterations on the code samples while writing the article, swap() was just a remnant. You guessed it correct, it was supposed to be replaced with tuple swaps: "(a,b)=(b,a)". Now, done. :)

titzer 1y ago

This is why Virgil has support for ranges in the language, which are better than slices. They are value types that represent a subset of a larger array. They can also be off-heap, which allows a Range<byte> to safely refer to memory-mapped buffers. https://github.com/titzer/virgil/blob/master/doc/tutorial/Ranges.md https://github.com/titzer/virgil/blob/master/doc/tutorial/Ra...

algorithmsRcool 1y ago
Isn't Span<T> the exact same concept?
- titzer 1y ago
  Conceptually they are almost identical, though Virgil has explicit source syntax for making a subrange. One important difference, according to [1] Span<T> can only live on the stack. There are no lifetime restrictions for Range<T> in Virgil. [1] https://learn.microsoft.com/en-us/archive/msdn-magazine/2018/january/csharp-all-about-span-exploring-a-new-net-mainstay https://learn.microsoft.com/en-us/archive/msdn-magazine/2018...
  - achandlerwhite 1y ago
    Memory<T> is the heap compatible version of Span<T> in C# for anyone curious.

rkagerer 1y ago

Array element accesses are bounds-checked in C# for safety. But, that means that there's performance impact... Why don't we have hardware support for this yet? (i.e. CPU instructions that are bounds-aware?) Edit: Do we? https://stackoverflow.com/questions/40752436/do-any-cpus-have-hardware-support-for-bounds-checking https://stackoverflow.com/questions/40752436/do-any-cpus-hav...

mwsherman 1y ago

I move between Go and C#. I wrote a zero-allocation package in Go [1] and then ported to C# — and the allocations exploded! I had forgotten, or perhaps never realized, that substrings in C# allocate. The solution was Spans. Notably, it caused me to realize that Go had “spans” designed in from the start. [1] https://github.com/clipperhouse/uax29 https://github.com/clipperhouse/uax29

neonsunset 1y ago
No, slices in Go are more akin to ArraySegment but with resizing/copy-on-append. It does not have the same `byref` mechanism .NET supports, which can reference arbitrary memory (GC-owned or otherwise) in a unified way as a single (special) pointer type.
- int_19h 1y ago
  Go pointers can point at the stack or inside objects just fine, they are exactly as expressive as C# unsafe pointers (i.e. more expressive than `ref`). What Go can't do is create a single-element slice out of a variable or pointer to it. But that just means code duplication if you need to cover both cases, not that it's not expressible at all.
  - kbolino 1y ago
    > What Go can't do is create a single-element slice out of a variable or pointer to it. var x int s := unsafe.Slice(&x, 1) fmt.Println(&x == &s[0]) // Output: true
    - int_19h 1y ago
      Good catch! That takes care of the unsafe pointer case, but not the safe ref case. There's no reason for this to be unsafe - you're asking for a 1-element slice, and the compiler knows that the variable is always going to be there as long as the reference exists. In C#, `Span<T>` has a (safe) constructor from `ref T`.
- 1y ago