Csharp

Exploring the .NET CoreFX Part 10: Performance Tuning Enumeration

Exploring the .NET CoreFX Part 10: Performance Tuning Enumeration

This is part 10 of my Exploring the .NET CoreFX Series. The .NET Core’s System.Collections.Immutable.ImmutableArray provides two enumerators. The first has been highly tuned for speed, and the second is a fallback for compatibility when it is required. The high-performance enumerator uses the following performance optimizations: The enumerator is a struct, rather than a class, so that it is stack-allocated rather than heap-allocated. The enumerator does not implement IEnumerator or IEnumerator, as this would require it to implement IDisposable.
Exploring the .NET CoreFX Part 9: Immutable Collections and the Builder Pattern

Exploring the .NET CoreFX Part 9: Immutable Collections and the Builder Pattern

This is part 9 of my Exploring the .NET CoreFX Series. Using the builder pattern to allow for easier construction of immutable objects is well-known. The .NET Core’s immutable collections assembly, System.Collections.Immutable, also uses the builder pattern, but for a slightly different reason: to improve the performance of making many changes to the collection. This is possible because, unlike the immutable collection itself, the builder pattern does not need to maintain the immutable collection’s invariants after each modification.
Exploring the .NET CoreFX Part 8: NullReferenceException Performance Tricks

Exploring the .NET CoreFX Part 8: NullReferenceException Performance Tricks

This is part 8 of my Exploring the .NET CoreFX Series. The .NET Core’s System.Collections.Immutable.ImmutableArray class implements an immutable wrapper around a normal C# managed array. This looks something like: public struct ImmutableArray<T> { internal T[] array; ... } ImmutableArray.array is lazy-initialized. Within the ImmutableArray class, there are a number of methods which have the precondition that ImmutableArray.array must be initialized. These preconditions must be checked before the method begins processing to make sure we handle invalid states correctly.
Exploring the .NET CoreFX Part 7: Reference Versus Structural Equality

Exploring the .NET CoreFX Part 7: Reference Versus Structural Equality

This is part 7 of my Exploring the .NET CoreFX Series. In the previous post, I referenced EqualityComparer.Default. If T does not implement IEquatable, EqualityComparer.Default will use the framework-defined Object.Equals(), which implements reference equality. However, many times you want to compare two types for structural equality (i.e. identical content) rather than reference equality (i.e. two references point to the same instance of the class). The interface IStructuralEquatable was defined to allow a class to explicitly implement structural, rather than reference equality.
Exploring the .NET CoreFX Part 6: Use IEquatable for Higher-Performance Equals()

Exploring the .NET CoreFX Part 6: Use IEquatable for Higher-Performance Equals()

This is part 6 of my Exploring the .NET CoreFX Series. Let’s say you are writing a custom IList which contains the following code: public class MyList<T> : IList<T> { private T[] array; ... public int IndexOf(T item) { for (int i = 0; i != array.Length; ++i) { if (this.array[i].Equals(item)) { return i; } } return -1; } } The above code uses T“s implementation of Object.Equals(), which is defined as:
Exploring the .NET CoreFX Part 5: Keep Indexers Trivial to Allow JIT Optimization

Exploring the .NET CoreFX Part 5: Keep Indexers Trivial to Allow JIT Optimization

This is part 5 of my Exploring the .NET CoreFX Series. This is a simple recommendation based on observations from System.Collections.Immutable. Recommendations Keep the implementation of an indexer as trivial as possible to allow the JIT optimization of removing array bounds checking to work. For example, don’t check if a member variable is null; just use it and allow the NullReferenceException to happen naturally. In other words, use: public T this[int index] { get { return this.
Exploring the .NET CoreFX Part 4: The Requires Convenience Class

Exploring the .NET CoreFX Part 4: The Requires Convenience Class

This is part 4 of my Exploring the .NET CoreFX Series. The System.Collections.Immutable project in the .NET CoreFX includes a convenience class called Requires, which looks like: internal static class Requires {[DebuggerStepThrough] public static T NotNull([ValidatedNotNull]T value, string parameterName) where T : class // ensures value-types aren't passed to a null checking method { if (value == null) { throw new ArgumentNullException(parameterName); } return value; } ... } This allows other methods to write code like:
Exploring the .NET CoreFX Part 3: Making Methods Debugger-Friendly

Exploring the .NET CoreFX Part 3: Making Methods Debugger-Friendly

This is part 3 of my Exploring the .NET CoreFX Series. System.Collections.Immutable uses a number of attributes to make it more debugger-friendly. Here are the key attributes: DebuggerStepThrough Occasionally a method is so simple that it doesn’t make sense to have the debugger step into it. The System.Diagnostics.DebuggerStepThroughAttribute instructs the debugger to step through the code instead of stepping into the code. Here is an example from System.Collections.Immutable: internal static class Requires {[DebuggerStepThrough] public static void Range(bool condition, string parameterName, string message = null) { if (!
Exploring the .NET CoreFX Part 2: Cache ThreadLocal Variables in Locals

Exploring the .NET CoreFX Part 2: Cache ThreadLocal Variables in Locals

This is part 2 of my Exploring the .NET CoreFX Series. Thread-local storage allows you to mark a global or static variable as local to a thread. In Win32, thread-local storage is provided by the functions TlsAlloc, TlsGetValue, TlsSetValue, and TlsFree. Similarly, C# provides System.ThreadStaticAttribute and System.Threading.ThreadLocal. Unfortunately, thread-local storage comes at a cost. Reading or writing a thread-local variable is far more expensive than reading or writing a local variable.
Exploring the .NET CoreFX Part 1: Annotate Pure Methods With PureAttribute

Exploring the .NET CoreFX Part 1: Annotate Pure Methods With PureAttribute

This is part 1 of my Exploring the .NET CoreFX Series. A pure method is a method that does not make any visible state changes. John Carmack, in his article In-Depth: Functional Programming in C++, notes many advantages of pure functions: Pure functions have a lot of nice properties. Thread safety. A pure function with value parameters is completely thread safe. With reference or pointer parameters, even if they are const, you do need to be aware of the danger that another thread doing non-pure operations might mutate or free the data, but it is still one of the most powerful tools for writing safe multithreaded code.