DEV Community: Aleh Karachun

.NET 10 Performance: The O(n^2) String Trap and the Zero-Allocation Quest

Aleh Karachun — Sat, 21 Mar 2026 13:08:00 +0000

"Premature optimization is the root of all evil." We’ve all heard it. But in the world of high-load cloud systems and serverless environments, there is another truth: "Ignoring scalability is the root of a massive AWS bill."

Today, we are doing a deep dive into .NET 10 string manipulation. We’ll explore how a simple += can turn your performance into a disaster and how to achieve Zero-Allocation using modern C# features.

1. The Big Picture: Scaling is a Cliff

In computer science, O(n) vs O(n^2) is often treated as academic theory. But when you visualize it, theory becomes a cold, hard reality. We compared three contenders:

Classic Concatenation: The quadratic O(n^2) path.
StringBuilder: The standard heap-allocated buffer.
ValueStringBuilder (Optimized): A ref struct living entirely on the stack.

Figure 1. Scaling performance overview.

If the log scale feels too abstract, look at the linear reality at N=10,000:

Figure 2. Linear comparison at maximum scale.

2. The Micro-Scale Paradox (N=10)

Engineering is about choosing the right tool for the right job. On a tiny scale (N=10), our "super-optimized" approach actually loses.

UseStringBuilder: 32.30 ns
UseStringConcatenation: 52.95 ns
UseValueStringBuilder_Optimized: ~107 ns

The Paradox Explained:
Why does the "optimized" method lose here? It comes down to the "Setup Tax." Initializing a ref struct and preparing a stackalloc buffer takes more time than the actual string processing when N is small.

Meanwhile, StringBuilder in .NET 10 has been heavily tuned for small-scale operations. It manages to avoid the heavy allocations of += while bypassing the complex initialization required by our manual stack-based approach. At this scale, the runtime's built-in optimizations are simply more efficient than manual memory management.

Figure 3. Execution time distribution for N=10.

Lesson: Don't over-engineer for the small stuff. For small-scale formatting or log messages, standard library tools provide the best balance of performance and maintainability.

3. The "GC Fingerprint" (N=10,000)

When we scale to 10,000 operations, the masks come off. String concatenation at this scale allocates 379.4 MB of garbage. This leads to what is called the "Camel Effect" on our density plots.

Figure 4. Impact of Garbage Collection on latency.

Now, compare this to the optimized Zero-Allocation method:

Figure 5. Predictability of zero-allocation execution.

Note on hardware physics: Even in Figure 5, where Zero-Allocation is achieved, a microscopic "tail" of jitter is still visible on the right. This isn't the Garbage Collector; it is the "physics of the hardware". OS interrupts, CPU context switching, and cache misses introduce these unavoidable micro-fluctuations. However, compared to the "Camel Effect" of GC pauses, this is just statistical noise, confirming the almost perfect predictability of our approach.

4. Engineering for Zero-Allocation

How did we achieve this? By staying off the Managed Heap entirely. We combined three pillars of modern .NET:

ref struct: Ensures our builder never escapes to the heap.
stackalloc char[256]: Allocates the initial buffer directly on the stack.
ISpanFormattable: Writes data directly into memory via TryFormat, avoiding intermediate ToString() allocations.

public void Process(ReadOnlySpan<Transaction> transactions)
{
    // 1. Initial buffer on the stack
    Span<char> buffer = stackalloc char[512];
    var vsb = new ValueStringBuilder(buffer);

    foreach (var tx in transactions)
    {
        // 2. Zero-allocation formatting
        tx.Amount.TryFormat(vsb.AppendSpan(10), out int written);
    }

    // 3. Final result (the only allocation)
    string result = vsb.ToString(); 
}

Conclusion: Be Pragmatic

The benchmark results demonstrate that the optimal string manipulation strategy depends entirely on the expected data volume and system requirements.

Small scale (N < 50): StringBuilder is technically the winner, offering 40% better performance and 50% fewer allocations than simple concatenation. However, concatenation remains an acceptable choice for one-off tasks where code readability is the top priority.
Medium scale (N < 1000): StringBuilder remains the standard efficient approach for general-purpose applications, providing linear scaling with manageable heap pressure.
High-performance / High-load: Implementation of Zero-Allocation patterns (e.g., ValueStringBuilder) is critical for systems with strict latency requirements. This approach eliminates bimodal distribution caused by Garbage Collection, ensuring deterministic execution time and lower memory throughput.

Final decision-making should balance code complexity against predictability. For high-concurrency environments like AWS Lambda, bypassing the managed heap is a primary strategy for cost and latency optimization.

The full source code and raw BenchmarkDotNet data are available on my GitHub:
👉 https://github.com/olegKarachun/dotnet-string-optimization-benchmarks

Battle of the Titans (Part 1): The Ultimate Go Lambda on AWS Graviton

Aleh Karachun — Thu, 19 Mar 2026 17:04:03 +0000

Hi everyone! Welcome to the first part of my series exploring AWS Lambda performance. My goal is to compare Go and .NET Native AOT in a realistic serverless environment.

To make this a fair benchmark, we aren't just deploying a "Hello World" function. Our Lambda simulates a standard combat task: it deserializes a JSON payload of financial transactions, filters them, calculates the total amount, and computes a SHA-256 hash of the IDs to generate a signature (simulating CPU load).

Today, we are focusing on setting up and optimizing the Go contender on ARM64 (Graviton).

1. The Infrastructure (AWS SAM)

We use AWS SAM (Serverless Application Model) to define our infrastructure. It allows us to describe resources declaratively and generates the underlying CloudFormation template.

Here is the core of our template.yaml:

CodeUri: bin/
Handler: bootstrap
Runtime: provided.al2023
Architectures:
  - arm64

Key takeaways

Runtime: provided.al2023: Amazon Linux 2023 is currently the recommended minimalist OS for compiled languages in AWS. It boots significantly faster than the legacy go1.x runtime.
Architectures: arm64: Targeting AWS Graviton processors. They use a RISC architecture that typically provides around 20% better price/performance for serverless workloads compared to x86_64.
Handler: bootstrap: When using custom runtimes, AWS Lambda expects the executable binary inside the deployment package to be named exactly bootstrap.

2. Compiling for Lambda

A standard go build works, but we can optimize it further for the Lambda environment. Here is the command we use:

GOOS=linux GOARCH=arm64 go build \
  -tags lambda.norpc \
  -ldflags="-s -w" \
  -o bin/bootstrap main.go

Key takeaways

GOOS=linux GOARCH=arm64: This enables cross-compilation, allowing us to build a Linux ARM64 binary directly from our local machine (even if it's x86).
-tags lambda.norpc: The al2023 runtime communicates with the Lambda service via an internal HTTP API. This tag tells the compiler to drop the legacy RPC compatibility code from the aws-lambda-go library, reducing the binary size and initialization time.
-ldflags="-s -w": These linker flags strip the symbol table and debug information, resulting in a leaner binary that loads into memory faster.

3. Local Testing and the "Error 255"

If you develop on an x86 (Intel/AMD) machine and try to test this locally using sam local invoke, you will likely hit a Fatal Error 255.

This happens because the Docker container spins up an ARM64 environment, but your host CPU cannot natively execute ARM instructions.

The fix: We need a translator. Running the multiarch/qemu-user-static Docker image solves this. QEMU intercepts the ARM commands and translates them into x86 instructions for your host CPU on the fly, allowing you to seamlessly test the production binary locally.

4. Anatomy of a Cold Start

When you run sam deploy --guided, AWS packages the binary, uploads it to S3, and updates the CloudFormation stack. But the most interesting part happens on the first invocation.

When we triggered the Lambda, CloudWatch reported an Init Duration of ~60 ms.

During these 54 milliseconds, AWS performed the following:

Allocated a Graviton-based server.
Provisioned an isolated Firecracker microVM.
Downloaded the deployment zip from S3 and extracted it.
Booted the provided.al2023 OS.
Loaded our bootstrap binary into memory.

Once the environment was warm, subsequent invocations (Warm Starts) took roughly 2 ms of compute time with a memory footprint of about 19 MB.

Conclusion

Go on ARM64 with the AL2023 runtime provides an excellent baseline. With extremely low memory consumption and cold starts consistently under 60ms, it is a highly efficient choice for serverless APIs.

What’s Next?

In Part 2, we will set up our challenger: .NET 10 Native AOT. We will explore how to configure the C# project with Zero-Allocation techniques and Source Generators to see if it can match or beat Go's numbers.

The full source code for this setup is available in my GitHub repository:
👉 https://github.com/olegKarachun/aws-lambda-go-graviton