Today we continue the series by looking at a pair of powerful, related features in C# 7.3: ref return values and local variables. These enable some great optimizations, so let’s look at the IL2CPP output for them to make sure it’s as good as it looks.
Posts Tagged performance
Last week we started exploring the new features of C# 7.3 in Unity 2018.3 by delving into tuples. This week we’ll continue and look at pattern matching. Read on to see how the many forms of pattern matching are actually implemented by IL2CPP!
Unity 2018.3 officially launched last Thursday and with it comes support for the very latest version of C#: 7.3. This includes four new versions—7.0, 7.1, 7.2, and 7.3—so it’s a big upgrade from the C# 6 that we’ve had since 2018.1. Today we’ll begin an article series to learn what happens when we use some of the new features with IL2CPP. We’ll look at the C++ it outputs and even what the C++ compiles to so we know what the CPU will end up executing. Specifically, we’ll focus on the new tuples feature and talk about creating, naming, deconstructing, and comparing them.
Native collections are funny things. On one hand they’re structs, which are supposed to be value types that get copied on assignment. On the other hand, they act like reference types because they contain a hidden pointer internally. This can make using and implementing them difficult to understand, especially in the context of a ParallelFor job. Today we’ll examine more closely how to properly support ParallelFor jobs, especially with ranged containers like NativeList<T>.
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.
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#.
