5 C# Mistakes That Slow Your Workflow and How to Fix Them

1. The Hidden Cost of LINQ in Performance-Critical Paths

Many C# developers reach for LINQ by default, appreciating its readability and expressiveness. However, LINQ can introduce significant overhead in tight loops or hot paths, leading to increased allocations, slower execution, and even hidden bugs due to deferred execution. This section explores the problem and provides concrete fixes.

When you write code like myList.Where(x => x > 10).Select(x => x * 2).ToList(), you're chaining multiple iterators that each allocate objects on the heap. In a loop called thousands of times per second, these allocations add up and pressure the garbage collector. For example, consider a method that processes a stream of sensor readings: a naive LINQ implementation could cause a 30% increase in execution time compared to a hand-coded loop due to allocation overhead.

Understanding the Allocation Tax

Each LINQ operator (Where, Select, etc.) creates a new iterator class instance. For a chain of three operators, you get three allocations per iteration. With 100,000 iterations, that's 300,000 allocations. The garbage collector must then collect those objects, causing pauses. In contrast, a foreach loop with inline conditions typically avoids these allocations. Additionally, deferred execution can lead to multiple enumerations of the same sequence, doubling the work.

Scenario: Real-Time Data Processing

Imagine a real-time dashboard that aggregates metrics every 100 milliseconds. The original code used LINQ to filter and project data: var result = data.Where(d => d.IsActive).Select(d => d.Value).Average();. Profiling revealed that this single line accounted for 40% of CPU time. Replacing it with a simple loop reduced CPU usage by 60% and eliminated thousands of allocations per second. The fix: double sum = 0; int count = 0; foreach (var d in data) { if (d.IsActive) { sum += d.Value; count++; } } double avg = sum / count;. This pattern is faster and allocation-free.

When to Keep LINQ

LINQ is still great for readability in non-critical code, such as UI data binding or report generation. Use it when performance isn't a concern. For hot paths, measure first: use BenchmarkDotNet to compare approaches. Often, a hybrid approach works best—use LINQ for complex filtering but switch to loops for performance-critical sections. Also consider IEnumerable pooling or using Array.ForEach where appropriate.

In summary, LINQ is a powerful tool but not a free lunch. By being aware of allocation overhead and deferred execution, you can choose the right tool for each scenario, keeping your code both readable and fast.

2. Misunderstanding Async/Await: Blocking Calls and Deadlocks

Asynchronous programming in C# can dramatically improve responsiveness, but common mistakes like blocking on async code or mixing sync and async can lead to deadlocks, thread pool starvation, and slower overall throughput. This section explains why these mistakes happen and how to fix them.

The classic anti-pattern is using .Result or .Wait() on a Task in a synchronous context, such as inside a constructor or an ASP.NET controller action that isn't async. This blocks the calling thread, which in a UI or ASP.NET context can cause a deadlock if the synchronization context requires that thread to complete the async operation. For example, var result = MyAsyncMethod().Result; in an ASP.NET Core action will block the request thread, reducing scalability and risking deadlocks.

Understanding Synchronization Contexts

In older ASP.NET (non-Core) and WPF/UWP apps, a synchronization context marshals continuations back to the original context (e.g., UI thread). When you block a thread in that context and the async method tries to resume on that same thread, you get a deadlock—the context thread is blocked waiting for the task, and the task cannot complete because it needs the context thread. In ASP.NET Core, there is no synchronization context by default, so deadlocks are less common, but blocking still wastes a thread.

Scenario: ASP.NET Core Endpoint

A team noticed that their web API endpoint that called an external service was slow under load. The code looked like: public IActionResult GetData() { var data = _service.FetchDataAsync().Result; return Ok(data); }. Under high concurrency, thread pool threads were blocked waiting for I/O, causing requests to queue. The fix: change the action to async: public async Task<IActionResult> GetData() { var data = await _service.FetchDataAsync(); return Ok(data); }. This freed the thread during I/O, allowing the server to handle more concurrent requests. The throughput improved by 300%.

Best Practices for Async

First, use async all the way: if a method calls an async method, make it async too and use await. Avoid .Result or .Wait()—instead, restructure the code to be async from the top down. For constructors, use a factory pattern or Lazy<Task<T>>. For event handlers, use async void only as a last resort (e.g., for UI events). Use ConfigureAwait(false) in library code to avoid capturing the synchronization context and improve performance. For example, await _service.GetAsync().ConfigureAwait(false);.

By following these practices, you can avoid deadlocks and make your application more responsive under load, truly leveraging the power of async.

3. Overusing Exceptions for Control Flow

Exceptions in C# are designed for exceptional, unexpected conditions—not for regular control flow. Yet many developers use exceptions to validate input, check for existence, or signal expected outcomes. This misuse can slow your application significantly because throwing and catching exceptions is expensive.

When you throw an exception, the runtime must walk the stack to gather information, allocate exception objects, and potentially trigger first-chance exception handlers. In a tight loop, this overhead can be catastrophic. For example, parsing user input with int.Parse() inside a try-catch block when invalid input is common will throw many exceptions. A better approach is to use int.TryParse(), which returns a bool and avoids exceptions entirely.

Understanding Exception Costs

Throwing an exception can be 1,000 to 10,000 times slower than a normal return path, depending on the stack depth. Additionally, throwing exceptions causes the JIT to deoptimize code, making subsequent execution slower. In a high-throughput service, even a few exceptions per request can degrade performance. For instance, a validation pattern that throws on each invalid field can cause thousands of exceptions per second, consuming CPU and memory.

Scenario: Input Validation in a Web API

A team built an API endpoint that accepted a list of IDs and validated each one: foreach (var id in ids) { try { int parsed = int.Parse(id); ... } catch { ... } }. Performance testing showed the endpoint handled only 50 requests per second. Profiling revealed that 80% of CPU time was spent in exception handling. Changing to int.TryParse and returning error messages without exceptions increased throughput to 800 requests per second. The fix was simple and did not reduce code clarity.

Alternatives to Exceptions

For expected conditions, use return codes, the Try pattern (like TryParse), or the Result monad pattern (e.g., using OneOf or FluentResults libraries). For input validation, use data annotations or a validation library like FluentValidation. Reserve exceptions for truly unexpected failures, such as network outages or missing configuration files. When you do throw exceptions, throw specific exception types (e.g., NotFoundException) instead of generic Exception to aid debugging.

By reserving exceptions for exceptional situations, you make your code faster and more predictable, and you avoid masking bugs by swallowing exceptions.

4. Inefficient String Concatenation in Loops

String immutability in C# means that each concatenation creates a new string object. In a loop, this leads to quadratic time complexity and excessive garbage collection. Many developers still use += to build strings in loops, unaware of the better alternatives.

Consider building a large string from a list of lines: string result = string.Empty; foreach (var line in lines) { result += line + Environment.NewLine; }. For 10,000 lines, this creates roughly 10,000 intermediate strings, each copy of the previous content. The total memory allocated is O(n^2), and the GC must collect all those intermediate strings. This pattern can turn a fast operation into a slow one, especially for large collections.

Understanding String Builder

The StringBuilder class maintains a mutable buffer that grows as needed. It avoids creating intermediate strings until ToString() is called. Using StringBuilder in loops reduces allocations from O(n^2) to O(n) and drastically reduces GC pressure. For example, the above loop becomes: var sb = new StringBuilder(); foreach (var line in lines) { sb.AppendLine(line); } string result = sb.ToString();. This is both faster and more memory-efficient.

Scenario: Generating a CSV Report

A team generated a CSV report by concatenating rows: string csv = ""; foreach (var row in rows) { csv += FormatRow(row) + " "; }. With 50,000 rows, the operation took 12 seconds and allocated over 2 GB of memory. Switching to StringBuilder reduced the time to 0.2 seconds and allocated only 5 MB. The improvement was dramatic and required minimal code change.

Other Alternatives

For very simple cases, string.Join is efficient and readable: string result = string.Join(Environment.NewLine, lines);. For complex formatting, consider string.Format or interpolation outside loops. For building JSON/XML, use dedicated serializers like System.Text.Json which are optimized. In performance-critical paths, also consider using ArrayPool<char> to reuse buffers.

By using the right string construction technique, you can avoid hidden performance pitfalls and keep your code fast and responsive, especially when dealing with large textual data.

5. Ignoring Memory Allocation and Garbage Collection

Even if you avoid the mistakes above, your code may still suffer from excessive memory allocations that trigger frequent garbage collection (GC) pauses. In high-throughput applications, GC pauses can cause latency spikes and reduce throughput. This section covers common allocation patterns and how to minimize GC pressure.

Every time you allocate a reference type on the heap, the GC must eventually clean it up. In server applications, short-lived objects (generation 0) are collected frequently, but if they survive to generation 1 or 2, collection pauses can be significant. Common sources of unnecessary allocations include: using LINQ with intermediate collections, boxing value types (e.g., passing an int to a method expecting object), using params arrays in hot paths, and allocating large arrays frequently.

Understanding Boxing

Boxing occurs when a value type is converted to a reference type, like object o = 42;. This allocates a heap object. In code that uses collections like ArrayList (which is obsolete but still in use) or generic methods with constraints that cause boxing, these allocations add up. For example, using string.Format with value type arguments boxes them. The fix: use generics, avoid ArrayList in favor of List<T>, and use string.Format with ToString() calls or use StringBuilder.Append overloads that accept value types directly.

Scenario: High-Frequency Trading Feed

A trading application processed thousands of messages per second. Profiling showed that 30% of CPU time was spent in GC. The culprits included using LINQ with ToList() in every processing step, and using foreach over IEnumerable that allocated enumerators (for List<T> this doesn't allocate, but for other collections it might). The team replaced LINQ with loops, used struct enumerators where possible, and pooled objects using ObjectPool. GC time dropped to 5%, and throughput doubled.

Tools and Techniques

Use memory profilers like dotMemory or PerfView to identify allocation hotspots. Look for high allocation rates in hot paths. Reduce allocations by: reusing buffers (ArrayPool), using Span<T> to avoid copies, implementing object pooling for frequently created objects, and using readonly struct to avoid defensive copies. Also consider using ValueTask to avoid Task allocations when the result is often synchronous.

By being mindful of memory allocations, you can reduce GC pauses and make your application more consistent and responsive, especially under heavy load.

6. Tools and Techniques for Measuring and Fixing C# Performance

To fix performance issues, you need to measure before and after. This section covers essential tools and workflows for identifying the slowdowns described in earlier sections, along with best practices for integrating performance testing into your development cycle.

Many developers rely on intuition to find performance bottlenecks, but intuition is often wrong. A profiler gives you hard data on where time and memory are spent. For CPU profiling, use dotTrace or PerfView. For memory profiling, dotMemory or Visual Studio Diagnostic Tools. For microbenchmarking, BenchmarkDotNet is the gold standard—it runs multiple iterations, warms up the JIT, and reports statistical data.

Setting Up BenchmarkDotNet

Add the NuGet package BenchmarkDotNet to a console project. Create a class with methods marked with [Benchmark]. For example, compare LINQ vs loop: [Benchmark] public double LinqAverage() => data.Where(d => d.IsActive).Average(d => d.Value); and [Benchmark] public double LoopAverage() { ... }. Run in Release mode without debugger attached. BenchmarkDotNet will output a table with mean time, allocation, and error margins. Use these results to decide which implementation to use.

Integrating Performance Tests into CI

To prevent regressions, run benchmarks in your CI pipeline. Use BenchmarkDotNet's ability to compare results against a baseline. Set thresholds—for example, fail the build if a benchmark's mean time increases by more than 10%. This ensures that performance is tracked over time. Also, consider using GC.GetAllocatedBytesForCurrentThread() in unit tests to assert allocation counts in critical methods.

Quick Reference Table: Tools and Their Use Cases

By incorporating these tools into your workflow, you can make data-driven decisions and avoid shipping code that slows everyone down.

7. Frequently Asked Questions About C# Performance

This section answers common questions developers have about C# performance, addressing misconceptions and providing clarity on best practices.

Q: Is LINQ always slower than a loop? Not always. For small collections or one-off operations, the overhead is negligible. The difference matters in hot paths with many iterations. Always profile before optimizing. Use LINQ for readability in non-critical code.

Q: Should I use async everywhere? No. Use async for I/O-bound operations (file, network, database). For CPU-bound work, use Task.Run only if you need offloading from UI thread. Adding async to a method that just does a small computation adds overhead.

Q: How do I know if my app is GC-bound? Monitor GC time using performance counters (% Time in GC) or a profiler. If GC time exceeds 10-15% of CPU time, you need to reduce allocations. Also check for high gen 2 collection rates.

Q: Is string.Format faster than concatenation? For a few parts, concatenation (+) is fine. For complex formatting with many parts, StringBuilder or string.Create is better. string.Format parses the format string each time, so it's slower than interpolation in a loop.

Q: What about Span<T>? Span<T> and Memory<T> are great for reducing allocations when working with arrays or strings. They allow you to slice data without copying. Use them in APIs that process buffers to avoid extra allocations.

Q: Should I use struct to avoid allocations? struct can help but can also cause performance problems if passed by value frequently (causing copying). Use struct for small, immutable types that are often stored in arrays. Use readonly struct to prevent defensive copies.

These answers provide a starting point for making informed decisions, but always measure in your specific context.

8. Conclusion and Next Steps

We've covered five common C# mistakes that slow down your workflow: overusing LINQ, mishandling async, using exceptions for control flow, inefficient string concatenation, and ignoring memory allocations. Each of these pitfalls can be fixed with awareness and the right techniques.

Start by auditing your codebase for these patterns. Use the tools mentioned—BenchmarkDotNet for microbenchmarks, profilers for CPU and memory, and CI integration to catch regressions. Prioritize fixes based on impact: if a hot path uses LINQ or throws exceptions, that's likely a quick win. If GC time is high, look for allocation-heavy code.

Remember that performance is a feature. By writing efficient C#, you not only make your application faster but also reduce hosting costs and improve user experience. Share these practices with your team to build a culture of performance awareness. As of May 2026, the .NET ecosystem continues to evolve with new features like Source Generators and NativeAOT that can further improve performance—stay updated.

Finally, don't over-optimize prematurely. Write clear code first, measure, then optimize the hot spots. The goal is to write code that is both maintainable and fast. Use the checklist below as a quick reference for your next code review:

• Are LINQ queries used in loops or hot paths? Consider replacing with loops.
• Is there any blocking on async code (.Result, .Wait)? Make the call stack async.
• Are exceptions used for expected conditions? Use Try methods or result types.
• Is string concatenation done in a loop? Use StringBuilder or string.Join.
• Are there excessive allocations? Profile and reduce with pooling or structs.

Implement these changes incrementally, and you'll see tangible improvements in your development speed and application performance.