Question: Where is the difference between: "Microsoft.Toolkit.HighPerformance.Buffers.SpanOwner<T>" and "DotNext.MemoryRental<T>"?

[CodingMadness]

Title.

src for "SpanOwner": https://learn.microsoft.com/en-us/dotnet/communitytoolkit/high-performance/spanowner

I cant quite grasp in what scenario yours may be better or equal to that type? I liked from your type that it may rent from whatever pool depending on the size needed, although I dont know if the reasoning-algorithm for that beats the purpose of "SpanOwner" from "Microsoft.Toolkit.HighPerformance" Nuget-package.

Any advise to this is very very appreciated cause I am in process to determine the proper buffering-strategy and would be cool to get the best one selected ^^

Btw very strong and dedicated work you have put in here, you earned my highest respect!

[sakno]

SpanOwner<T> is a stack-only buffer type according to its description, i.e. ref type. It cannot be used inside of async methods. The closest counterpart from .NEXT is MemoryRental<T> ref type. But, at the closer look, they are different. MemoryRental<T> simplifies an implementation of memory allocation strategy when you need to choose between stack-allocated memory (for small buffers) and large buffers:

const int stackallocThreshold = 20;
var memory = size <=stackallocThreshold
  ? new MemoryRental<byte>(stackalloc byte[stackallocThreshold], size)
  : new MemoryRental<byte>(size);

You can find a lot of places in .NEXT codebase that use this pattern.

MemoryOwner<T> is a regular value type (not ref) that can be used inside of async context. Thus, it can't be used to make abstraction over stack-allocated memory. Its counterpart from Community Toolkit is MemoryOwner<T>, surprise 😄 (I never tried to copy-paste from Community Toolkit implementation, moreover, I even didn't know about it in the beginning of .NEXT project). However, implementation from .NEXT is different:

• It supports IMemoryOwner<T> interface as a rented memory holder in addition to custom ArrayPool<T>
• As a result, it allows to use any memory that can be represented by T[], ArrayPool<T> or IMemoryOwner<T>
• Typically, it is combined with MemoryAllocator<T> delegate type that represents extension point to the caller code and allows to provide any custom memory rental strategy. For instance, DotNext.Unsafe library exposes unmanaged memory allocator that allocates the memory out of GC control. And it still uses MemoryOwner<T> to represent the allocated memory.
• It supports indexer
• It supports realloc

[sakno]

Both types provide low-level API to work with rented memory. If you are interested in growable (dynamic) buffers built on top of these types I recommend you to take a look at this article.

[CodingMadness]

First, thx alot for the detailed explanation!

Would there be 1) any benefit, in actually creating a hybrid buffer, who takes any give (sizeOf(T) * count) and checks of HOW MUCH of that (sizeOf(T) * count) does actually fit inside a reasonable stackalloc (lets say 1-2 KB) and THE REMAINING of that size-expression will be rented from a shared pool?

example:

const int stackallocThreshold = 2048;
int sizeOfTInBytes= (sizeOf(T) * count);

int diff = Math.Abs(stackallocThreshold  - sizeOfTInBytes);

   //hypothetical ctor()...!
  ///AllocationOptions= AllocationOptions.StackOnly,   AllocationOptions.PoolOnly,   AllocationOptions.UseBoth
  ///it will link both buffers internally 'somehow'
  //'diff' shall be rented from the pool and 'sizeOfTInBytes' on the stack via stackalloc
  //both memory-segments shall be linked internally to work for the user seemingly as if it would be a contigeous buffer in either stack or pool
using MemoryRental<T> result = sizeOfTInBytes<= stackallocThreshold ? 
     new MemoryRental<T>(stackalloc T[stackallocThreshold], count) : 
     new MemoryRental<T>(AllocationOptions.UseBoth, diff,  sizeOfTInBytes);

Would this approach yield any benefit in your opinion?

Best regards!

[CodingMadness]

and btw, I do ofc "2048 / sizeOf(T) " which gives you the accepted byteCount,

[sakno]

Max stack size depends on OS. On Windows, it is 1 MB.

OS	Process Stack Size	Thread Stack Size
Darwin (macOS, iOS, etc)	8 MiB	512 KiB
FreeBSD	8 MiB	2 MiB
OpenBSD (before 4.6)	8 MiB	64 KiB
OpenBSD (4.6 and later)	8 MiB	512 KiB
Windows	1 MiB	1 MiB
Alpine 3.10 and older	8 MiB	80 KiB
Alpine 3.11 and newer	8 MiB	128 KiB
GNU/Linux	8 MiB	8 MiB

And you don't know how your code will be used by potential consumer, e.g. you don't know how many frames and stack-allocated space on top of the stack already.

[CodingMadness]

Okay wow, I dont know to this day why only windows decide for such bad stack utilization... Nevermind

I have one last question, where is the difference between your MemoryRental and BufferWriterSlim they seem to do pretty much the same, no? I have the feeling with some other buffers too

[sakno]

BufferWriterSlim is a growable dynamic buffer while MemoryRental not. You can add as many elements as you want to BufferWriterSlim. It transparently reallocates the internal buffer. MemoryRental can't grow. They have the same difference as List<T> and T[].

[CodingMadness]

yea well I fully oversaw the growing aspect of it lol, my appologize, okay i have all infos, thx alot dude! keep going with this lib you are doing really well with it and I cant thank you enough for it !

[sakno]

cant thank you enough for it

There is a way to do that 😄 Just mark this discussion as answered