June 26th, 2023
Massive compile times are a drag. While excessive dependencies, careless use of libraries, and inefficient data structures and algorithms play a huge part in this, it's also important to use the language efficiently. Here are some examples of how to use language features efficiently in C#. These practices directly impact compilation speed, though the benefits can vary greatly. Trust your profiler!
Generics are a powerful feature, but each generic instantiation creates more work for the compiler. If a method heavily uses generics and it's not necessary, consider if there's a way to achieve the same functionality without them.
// Instead of this
public void DoSomething<T>(T item)
{
// ...
}
// Consider this, if possible
public void DoSomething(object item)
{
// ...
}
Reflection can be costly in terms of performance and can increase compile times. If you're using reflection to access properties or methods, consider if there's a way to do the same thing without reflection.
// Instead of this
var propertyInfo = typeof(MyClass).GetProperty("MyProperty");
var value = propertyInfo.GetValue(myObject);
// Consider this
var value = myObject.MyProperty;
The dynamic keyword in C# defers type checking to runtime, which can slow down compile times. If you're using dynamic, consider if there's a way to achieve the same functionality with static typing.
// Instead of this
dynamic x = GetSomeValue();
// Consider this
var x = GetSomeValue();
The async/await keywords are a powerful tool for writing asynchronous code, but they do add some overhead. If you're using async/await in a method that doesn't actually need to be asynchronous, consider making it synchronous.
// Instead of this
public async Task DoSomething()
{
// ...
}
// Consider this, if the method doesn't need to be asynchronous
public void DoSomething()
{
// ...
}
Nullable reference types are a new feature in C# 8.0 that can help catch null reference exceptions. However, they do add some overhead to the compilation process. If you're using nullable reference types in a part of your code where null references aren't a concern, consider turning them off for that part of your code.
Auto-properties are a convenient way to create properties with a default getter and setter, but they can be slower to compile than regular properties. If you have an auto-property that could be a regular field, consider making it a field.
// Instead of this
public int MyProperty { get; set; }
// Consider this
public int MyField;
Default interface methods are a new feature in C# 8.0 that allow you to provide a default implementation of a method in an interface. However, they can be slower to compile than regular interface methods. If you're using default interface methods where a regular abstract class would suffice, consider using an abstract class instead.
// Instead of this
public interface IMyInterface
{
void MyMethod()
{
// default implementation
}
}
// Consider this
public abstract class MyAbstractClass
{
public virtual void MyMethod()
{
// default implementation
}
}
Pattern matching is a powerful feature in C# that can make your code more readable and expressive. However, complex pattern matching can be slower to compile than equivalent if-else statements. If you're using complex pattern matching, consider if there's a way to simplify it or replace it with if-else statements.
// Instead of this
var result = item switch
{
TypeA a => a.Property,
TypeB b => b.Property,
_ => throw new InvalidOperationException()
};
// Consider this
var result = item is TypeA a ? a.Property : ((TypeB)item).Property;Tuples can be a convenient way to return multiple values from a method, but they can be slower to compile than regular classes or structs. If you're using tuples extensively, consider if there's a way to replace them with regular classes or structs.
// Instead of this
public (int, string) GetValues()
{
// ...
}
// Consider this
public class Result
{
public int Value1 { get; set; }
public string Value2 { get; set; }
}
public Result GetValues()
{
// ...
}
Deep inheritance hierarchies can become complex and hinder compilation speed due to the extensive interdependencies and cascading changes. Composition allows for more flexible and modular code by combining smaller, reusable components, reducing complexity and enhancing compilation performance.
// Instead of this
class Grandparent { }
class Parent : Grandparent { }
class Child : Parent { }
// Consider this
class Child
{
private Grandparent _grandparent;
private Parent _parent;
}Events in C# can be expensive in terms of performance because they involve delegate invocation, event subscriptions, and event handling overhead. If events are used extensively, it may be more efficient to consider simpler constructs like direct method calls or callbacks to improve performance.
// Instead of this
public event Action MyEvent;
// Consider this
public Action MyDelegate;Boxing and unboxing involve converting value types to reference types and vice versa. This process incurs performance overhead due to memory allocations and type conversions. Minimizing their use in code helps improve performance by reducing unnecessary memory operations and type conversions.
// Instead of this
object obj = 123; // boxing
int num = (int)obj; // unboxing
// Consider this
int num = 123;Excessive try/catch blocks can slow down compilation because exception handling involves additional runtime checks and handling mechanisms. Exceptions should be used for exceptional cases, such as handling errors or exceptional conditions, rather than for regular control flow to maintain efficient and optimized code compilation.
// Instead of this
try
{
// some code
}
catch (Exception)
{
// handle exception
}
// Consider this
if (someCondition)
{
// handle condition
}
else
{
// some code
}Anonymous types can slow down compilation because the compiler needs to infer and generate the type information at compile time. Defining proper classes or structs upfront provides explicit type information, leading to faster compilation and better code organization and maintainability.
// Instead of this
var anon = new { Name = "John", Age = 30 };
// Consider this
class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
var person = new Person { Name = "John", Age = 30 };Extension methods can slow down compilation because the compiler needs to check if an extension method is applicable to a given type. If you use extension methods extensively, it can introduce additional overhead. In such cases, using regular methods instead of extension methods may help improve compilation performance.
// Instead of this
public static class StringExtensions
{
public static bool IsNullOrEmpty(this string str) => string.IsNullOrEmpty(str);
}
// Consider this
public static class StringUtils
{
public static bool IsNullOrEmpty(string str) => string.IsNullOrEmpty(str);
}Extensive use of var can slow down compilation because the compiler needs to infer the type of the variable, which takes additional time. Specifying the type explicitly can help improve compilation speed by reducing the need for type inference.
// Instead of this
var num = 123;
// Consider this
int num = 123;Nullable types can slow down compilation due to additional code generation for handling null values. Consider alternatives to extensive use of nullable types.
// Instead of this
int? num = null;
// Consider this
int num = -1; // use a sentinel value insteadInterop services can slow down compilation due to additional code generation for marshaling data. Consider managed code alternatives for extensive use of interop services.
// Instead of this
[DllImport("user32.dll")]
public static extern int MessageBox(IntPtr hWnd, string text, string caption, int type);
// Consider this
// Use managed code alternatives where possibleOperator overloading can make code more readable because it allows you to use familiar operators (like + or *) with custom types, making the code more intuitive and expressive. However, the compiler needs to analyze and resolve the overloaded operators, which can slow down compilation, especially if there are many overloaded operators in the codebase. Using regular methods for complex operations can alleviate the compilation slowdown while still achieving the desired functionality.
// Instead of this
public static Complex operator +(Complex c1, Complex c2) => new Complex(c1.Real + c2.Real, c1.Imaginary + c2.Imaginary);
// Consider this
public static Complex Add(Complex c1, Complex c2) => new Complex(c1.Real + c2.Real, c1.Imaginary + c2.Imaginary);The params keyword allows flexibility in passing a variable number of arguments to a method. However, it can slow down compilation because the compiler needs to handle different argument lengths. By using method overloads instead, the compiler can optimize the code better, leading to faster compilation and potentially better performance.
// Instead of this
public void PrintNumbers(params int[] numbers)
{
foreach (var number in numbers)
{
Console.WriteLine(number);
}
}
// Consider this
public void PrintNumbers(List<int> numbers)
{
foreach (var number in numbers)
{
Console.WriteLine(number);
}
}The unsafe keyword allows writing code with pointers and unmanaged constructs, but it can slow down compilation because the compiler needs to perform additional checks and ensure the safety of the code. It involves validating pointer operations, memory access, and other low-level operations, which adds complexity and increases compilation time compared to safe code that doesn't require such checks. Consider safe code alternatives for extensive use of unsafe.
Attributes in code serve as a way to attach additional information or behavior to code elements, allowing for enhanced functionality or customization. However, the process of parsing and analyzing attributes during compilation can introduce overhead and slow down the compilation process, especially when dealing with a large number of attributes. Therefore, it is important to consider alternatives to extensive use of attributes to maintain faster compilation times and improve overall development efficiency.
// Instead of this
[Obsolete("Use NewMethod instead.")]
public void OldMethod() { }
// Consider this
// Use documentation comments to indicate that a method is obsolete
/// <summary>
/// This method is obsolete. Use NewMethod instead.
/// </summary>
public void OldMethod() { }The fixed keyword is used in C# to pin variables in memory when working with unsafe code or interop scenarios. However, the process of pinning variables can have an impact on compilation time due to the additional constraints imposed on the compiler. Therefore, it is advisable to use `fixed` sparingly and explore alternative approaches to achieve the desired functionality, if possible, in order to maintain optimal compilation performance.
// Instead of this
fixed (int* p = &number)
{
// some code
}
// Consider this
// Use safe code alternatives where possibleConversion operators can slow down compilation because they require additional analysis and resolution during the compilation process. The compiler needs to consider the semantics of the conversion operator and potentially perform type inference and overload resolution. This extra work can result in longer compilation times, especially when there are extensive use of conversion operators in the codebase. In contrast, regular methods have a more straightforward compilation process and can be more efficient for such scenarios. Additionally, regular methods provide clearer code and make the intentions of the code more explicit, which can improve maintainability and readability.
// Instead of this
public static implicit operator int(MyClass mc) => mc.Value;
// Consider this
public int ToInt() => Value;The checked and unchecked keywords in C# allow you to control how overflow is handled during numeric operations. By default, C# performs overflow-checking to ensure that values fit within their designated data types. However, enabling overflow-checking can have a performance impact as it requires additional runtime checks. If you find that the extensive use of checked and unchecked keywords is slowing down compilation, it's worth considering alternative approaches to minimize the need for overflow-checking or optimizing the code structure to reduce the number of operations that require overflow-handling.
// Instead of this
checked
{
int overflow = int.MaxValue + 1;
}
// Consider this
// Use careful arithmetic to avoid overflow
int safe = int.MaxValue - 1;The reason using the extern keyword can slow down compilation is because it requires the compiler to search for the implementation of the declared method in external files or libraries. This search process can take time, especially if there are many extern declarations. By reducing the use of extern and instead providing the method implementation directly in the code or using other techniques like function pointers, you can help improve the compilation speed.
// Instead of this
[DllImport("user32.dll")]
public static extern int MessageBox(IntPtr hWnd, string text, string caption, int type);
// Consider this
// Use managed code alternatives where possibleThe volatile keyword allows for concurrent access and modification of a variable by multiple threads without the need for explicit synchronization. However, the use of volatile can introduce some overhead during compilation because the compiler needs to enforce the visibility and ordering semantics required for thread safety. If you have extensive usage of volatile, it may be more efficient to use other synchronization constructs, such as locks or atomic operations, which can provide better control over synchronization and potentially improve performance.
// Instead of this
private volatile int _counter;
// Consider this, if possible
private int _counter;
private readonly object _lock = new object();
public void IncrementCounter()
{
lock (_lock)
{
_counter++;
}
}The [ThreadStatic] attribute introduces additional complexity and overhead during the compilation process because it requires the compiler to generate separate code paths for each thread. This can lead to increased compilation time, especially in larger codebases or projects with many threads. On the other hand, the ThreadLocal<T> class is implemented in a way that does not impact compilation significantly, resulting in faster compile times.
// Instead of this
[ThreadStatic]
private static int _field;
// Consider this
private static ThreadLocal<int> _field = new ThreadLocal<int>();Using constructor parameters instead of object initializers can potentially improve compile speed because it allows the compiler to resolve dependencies at compile time rather than evaluating them at runtime. This reduces the need for runtime reflection and can lead to faster compilation times.
// Instead of this
var obj = new MyClass { Property1 = value1, Property2 = value2 };
// Consider this
var obj = new MyClass(value1, value2);Using regular properties with backing fields instead of auto-implemented properties can affect compile times because the compiler needs to generate additional code for the getter and setter methods of the properties. This can increase the complexity and size of the compiled output, leading to longer compilation times. Instead of using auto-implemented properties, consider using regular properties with backing fields.
// Instead of this
public int MyProperty { get; set; }
// Consider this
private int _myField;
public int MyProperty
{
get { return _myField; }
set { _myField = value; }
}Complex LINQ queries involve more intricate logic and expression trees, which require additional analysis and transformation steps during the compilation process. The compiler needs to interpret the query syntax, infer types, and generate appropriate code to execute the query. These extra steps can contribute to longer compilation times compared to simpler loops that have straightforward and direct code execution.
// Instead of this
var result = myList.Where(x => x.SomeProperty > 10).Select(x => x.OtherProperty);
// Consider this
var result = new List<OtherType>();
foreach (var item in myList)
{
if (item.SomeProperty > 10)
{
result.Add(item.OtherProperty);
}
}
The yield keyword introduces additional complexity to the compilation process because it requires generating state machine code to handle the iterator logic. This extra step can increase the compilation time, especially when there are numerous yield statements. Using regular loops instead of yield eliminates this overhead and can result in faster compilation.
// Instead of this
public IEnumerable<int> GetNumbers()
{
for (int i = 0; i < 10; i++)
{
yield return i;
}
}
// Consider this
public List<int> GetNumbers()
{
var numbers = new List<int>();
for (int i = 0; i < 10; i++)
{
numbers.Add(i);
}
return numbers;
}Using index initializers can potentially affect compile times because the compiler needs to process and evaluate the initializer expressions at compile-time. In contrast, using Add method calls defers the evaluation to runtime, reducing the complexity and potentially improving the compilation speed.
// Instead of this
var dictionary = new Dictionary<int, string> { [1] = "one", [2] = "two" };
// Consider this
var dictionary = new Dictionary<int, string>();
dictionary.Add(1, "one");
dictionary.Add(2, "two");Same thing happens with collection initializers. The compiler needs to generate additional code behind the scenes to handle the initialization, leading to potentially longer compilation times. Again, instead of using collection initializers, consider using Add method calls.
// Instead of this
var list = new List<int> { 1, 2, 3 };
// Consider this
var list = new List<int>();
list.Add(1);
list.Add(2);
list.Add(3);Using string interpolation can affect compile times because it involves additional compile-time processing and string parsing compared to using string.Format(). String interpolation requires analyzing the interpolated expressions and generating the appropriate code, which can contribute to longer compile times, especially for complex string interpolations.
// Instead of this
var str = $"Hello, {name}!";
// Consider this
var str = string.Format("Hello, {0}!", name);Using null-conditional operators (?. and ?[]) can potentially impact compile times because the compiler needs to perform additional analysis to ensure the correct handling of null values. Regular null checks (if statements) are simpler and more straightforward, resulting in faster compilation.
// Instead of this
var length = str?.Length;
// Consider this
var length = str == null ? null : (int?)str.Length;Using null-coalescing operators (such as the ?? operator) introduces extra logic and branching in the code, which can make the compilation process more complex. The compiler needs to analyze and evaluate these operators, potentially leading to slower compilation times. On the other hand, regular null checks (e.g., if (variable != null)) are simpler and easier for the compiler to process, resulting in faster compilation.
// Instead of this
var value = input ?? "default";
// Consider this
var value = input == null ? "default" : input;Using expression-bodied members, such as lambda expressions or single-line methods, can lead to slower compile times because the compiler needs to analyze the code to infer types and resolve dependencies. Regular method bodies are more explicit and can improve compile times by reducing the complexity of the compilation process.
// Instead of this
public int Add(int a, int b) => a + b;
// Consider this
public int Add(int a, int b)
{
return a + b;
}Lambda expressions can slow down compilation due to the complexity of capturing variables and generating the corresponding delegate types. For extensive use of lambdas, using regular methods instead can help improve compilation speed and avoid potential slowdowns.
// Instead of this
Func<int, int> square = x => x * x;
// Consider this
int Square(int x) => x * x;
Using local functions instead of regular private methods can affect compile times because local functions are recompiled every time their containing method is called, whereas regular private methods are only compiled once. This can result in increased compilation overhead and longer build times, especially in larger codebases.
// Instead of this
public void DoSomething()
{
void LocalFunction() { /* ... */ }
LocalFunction();
}
// Consider this
private void MyPrivateMethod() { /* ... */ }
public void DoSomething()
{
MyPrivateMethod();
}These are just examples and the actual impact on compile times can vary depending on the specific use case and the complexity of the code. It's always a good idea to profile your build times to understand where the bottlenecks are before making changes.