Laszlo

Hello, I am Laszlo

Software-Engineer, .NET developer

Contact Me

Deep dive into .NET 11 Performance Improvements

In this series of posts, I am going to explore some of the most interesting .NET 11 performance improvements I learned about in Stephen Toub's blog post, Performance Improvements in .NET 11.

Each of my post focuses on one example from the original article, but digs a little deeper into one additional aspect that was not covered there. The series covers the following topics:

  1. Current post: Allocation free numbers
  2. Virtual generic method calls
  3. Vector zero equality
  4. Guid creation on Linux
  5. JIT generating implicit-else assembly instructions
  6. Guid equality
  7. Copy-on-write locking strategy

Allocation free numbers

Find out more »


Cancellation and Application Shutdown in an HTTP Server

I work on a personal project to build an ASP.NET Core server to serves HTTP/2 and HTTP/3 request-response pairs. This server integrates with ASP.NET Core applications, providing an alternative to Kestrel, IIS, HTTP.sys, and similar servers.

In most codebases I've encountered, significant effort goes into optimizing the startup process—starting the host, registering types, initializing background services, and establishing downstream connections. The goal is usually to achieve the fastest and most efficient application initialization. However, it's much less common for applications to pay the same attention to the shutdown process. That’s the focus of this post.

For server applications, there's often an assumption that requests are retriable. If a request is interrupted due to application shutdown, the client can simply retry. However, HTTP only guarantees safe retries for idempotent verbs and compliant servers.

At the infrastructure level, sophisticated hosting solutions can drain all active HTTP connections before terminating the server process. In a less controlled environments, a process might be terminated abruptly, without draining connections or even sending a SIGINT (CTRL+C) or SIGTERM signal.

Find out more »


Prefixed Integer Encoding with SIMD

HTTP/3 uses QPACK to encode header fields. QPACK uses the prefixed integer encoding from RFC 7541.

In a previous post I explored this encoding and compared it with QUIC's Variable Length Integer Encoding. That comparison considered using SIMD for prefixed-integer decoding.

This post explores encoding prefixed integers using SIMD.

Prefixed Integer Encoding

Find out more »


Integer Decoding with HTTP/3

HTTP/3 uses 2 different types of integer encoding in a transitive way. This blog post compares these encodings from size, decoding performance, and decoding complexity perspectives. These encodings are:

  • variable-length integer encoding defined by QUIC-TRANSPORT
  • prefixed integer encoding defined by HPACK

Seeing HPACK might be surprising as HTTP/3 uses QPACK for field compression. QPACK does not define the prefixed integer encoding; it inherits it from HPACK.

Both encodings encode positive integer numbers and zero.

Find out more »


Try-Catch-Finally in C#

Introduction

C#'s try-catch-finally statements are fundamental building blocks of the language. While most developers learn exception handling early in their careers and use it frequently in production applications, the mechanics can be surprisingly complex. Exception handling is often discussed during developer job interviews, and even experienced developers can struggle with some of its nuances.

A Complex Case

Let's examine a challenging code snippet that demonstrates these complexities. What does the following code print to the console?

Find out more »