Last week we looked at a new native collection type: NativeChunkedList<T>. This type saved us a lot of memory and gave us a faster way to dynamically grow an array. Unfortunately, iterating over it was quite a lot slower. Today we’ll speed it up for both IJob and IJobParallelFor. In doing so, we’ll learn more about how to create custom Unity job types and about how IEnumerable and IEnumerator work.
Posts Tagged performance
Today’s article is about a new native collection type: NativeChunkedList<T>. This type is great when you need a dynamically-resizable array that’s fast to add to and doesn’t waste a lot of memory. Read on to see how it’s implemented, see the performance report, and get the source code.
NativeArray<T> is great, but very limited in functionality. We can fix this surprisingly easily! Today we revive a two year old series that created the iterator project. Iterators are like a no-GC version of IEnumerable<T> and LINQ which have a lot of power but only support managed arrays (T[]) and List<T>. Today we’ll add support for NativeArray<T> and inherit support for the same functionality. We’ll also spruce up the project with proper unit tests, assembly definitions, and runtime tests to confirm that zero garbage is created. Read on to see how this was done and how to use iterators with NativeArray<T>.
LINQ’s CPU performance is quite poor, but how is it with memory? Does every LINQ function always create tons of garbage for the GC to collect, or are there exceptions that aren’t so bad? Today’s article tests out lots of LINQ functions to find out!
It’s been over three years since the last article on LINQ performance. That was all the way back in the Unity 5.0 days using Mono as a scripting backend. Today we’ll update that article’s test with Unity 2018.1 and IL2CPP to see how LINQ fares these days. Is it any better? Read on to find out!
A lot of powerful language features like LINQ require massive performance hits, but today we’ll discuss some easy, low-overhead ways to add some safety and usability to C#.
Writing multi-threaded code is one of the keys to maximizing performance. Currently, this means creating your own threads and synchronizing them with C# keywords like lock and volatile as well as .NET classes like [ThreadStatic] and Interlocked. Today we’ll take a look at how these are implemented behind the scenes by IL2CPP to get some understanding of what we’re really telling the computer to do when we use them.
C# has some powerful features like fixed-size buffers, pointers, and unmanaged local variable arrays courtesy of stackalloc. These are deemed “unsafe” since they all deal with unmanaged memory. We should know what we’re ultimately instructing the CPU to execute when we use these features, so today we’ll take a look at the C++ output from IL2CPP and the assembly output from the C++ compiler to find out just that.
Unity’s GC is a continual thorn in our sides. We’re constantly working around it by pooling objects, limiting use of language features, and avoiding APIs. We even call GC.Collect on load screens in the hopes that the GC won’t run during gameplay. Today’s article goes one step further and shows how to disable the GC completely so there’s zero chance it’ll run. We’ll also see how to turn it back on when we’re ready for it again.
There are many permutations of loops we can write, but what do they compile to? We should know the consequences of using an array versus a List<T>, for versus foreach, caching Length, and other factors. So today’s article dives into the C++ code that IL2CPP outputs when we write these various types of loops to examine the differences. We’ll even go further and look at the ARM assembly that the C++ compiles to and really find out how much overhead our choices are costing us.