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

Exploring the .NET CoreFX .net core csharp system.collections.immutable

Published: 2014-11-21

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

This is part 5/17 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:

1
2
3
4
5
6
7


public T this[int index]
{
    get
    {
        return this.array[index];
    }
}

not:

Exploring the .NET CoreFX .net core csharp system.collections.immutable

Published: 2014-11-20

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

This is part 4/17 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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


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 .net core csharp system.collections.immutable

Published: 2014-11-19

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

This is part 3/17 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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


internal static class Requires
{
    [DebuggerStepThrough]
    public static void Range(bool condition, string parameterName, string message = null)
    {
        if (!condition)
        {
            FailRange(parameterName, message);
        }
    }
}

DebuggerBrowsable

The System.Diagnostics.DebuggerBrowsableAttribute determines if and how a member is displayed in the debugger variable windows.

Exploring the .NET CoreFX .net core csharp system.collections.immutable

Published: 2014-11-18

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

This is part 2/17 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. System.Collections.Immutable uses a trick or two to help ameliorate this expense. For example, System.Collections.Immutable caches thread-local variables in local variables in a method to avoid unnecessary TLS hits on repeated access. Here’s some sample code which implements this:

Exploring the .NET CoreFX .net core csharp system.collections.immutable

Published: 2014-11-17

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

This is part 1/17 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.
Read more...

System.collections.immutable

Recommendations

DebuggerStepThrough

DebuggerBrowsable