I've recently discovered this project, which assuming it works as advertised (which I think wasn't really tested yet, since it seems to be a pretty new repo) sounds like a pretty good library to add into your toolbox.
For those that do not know, LINQ is basically a query language over collections in C#, that allows you (from the top of my head) to do stuff like
someList.Where(x => x.value < 10).OrderBy(x => x.priority).Select(x => x.name)
which would give you a IEnumerable list with names of elements where value is smaller than 10, ordered by priority.
However, using LINQ in performance critical code, such as per-frame Updates, is not really a good idea because it unfortunately does generate a lot of garbage (allocations for GC to collect). Having a version that doesn't allocate anything sounds awesome, assuming you are a fan of LINQ.
What are your thoughts? For me, it sounds like something really useful. While it's not really that difficult to avoid LINQ, I'm a fan of the simplicity and descriptive nature of the syntax, and not having to avoid it would be great. It does seem there are quite a few issues starting to pop up, but it's definitely a project that could be worth it to follow.
Some of LINQ functions do memory allocations in the background, which are then thrown away and left for the garbage collector to handle.
Here is an example what I mean - https://www.jacksondunstan.com/articles/4840
net 4 (framework) is very old.
MS has done a lot of optimizations across net 5 6 7 8 9, especially around using spans and allocations as well.
Is Unity still stuck on net 4?
I've picked the first example article I found, which was really old (Unity 2018), since I wasn't sure if the question was about what's garbage or how much, so I just wanted to illistrate the concept more than concrete numbers.
The ZLINQ repo does have a benchmark screenshot in readme and it does shows that LINQ still does allocations. It's not clear what the benchmark was ran on, but it shows mean of 200b of allocations, so LINQ probably still does them in some capacity.
Do you know how Zlinq does avoid allocations? I do understand that if you map, let's say from Integer to Integer, that you could do this in-place. But what about a mapping Integer to String?
My interpretation, without having used ZLINQ or actually analyzed it in-depth:
Zero allocations must be for the byte-/data-span traversal. When you transform them to deserialized interpreted data you can't avoid allocations.
It's useful when you're reading / querying from linear data, avoiding the whole LINQ provider accumulation and translation phase.