Last time we built our DHCP buffer with header fields. For a fully formed DHCP message, we also need to support DHCP options. Each option has a tag byte specifying its type, a length byte, and a number of data…
Let’s do DHCP: intro
We’ve been talking about high performance datagram scenarios but have so far used a contrived sample of sending mostly fixed size strings — not so realistic. That will change today, as we turn to one of the more famous datagram…
High performance datagramming: concurrency?
We’ve been looking at some tips and tricks for achieving high performance in a skeletal datagram server. And yet, the implementation so far is single threaded. This is fine if strict packet ordering must be maintained. But we’re talking about…
High performance datagramming: heap?
Last time, we looked at an implementation of a datagram server with and without channels. The non-channel solution ultimately won out in terms of performance. But that’s not all we can do to squeeze every ounce of throughput from this…
High performance datagramming: channels?
You may have heard of System.IO.Pipelines, a set of classes to aid in writing high performance streaming server code. But what about datagram scenarios, e.g. using UDP? That would seem like a job for System.Threading.Channels. Let’s try it and do…
TKey performance indicators: custom types
Last time, we covered the effect of various primitive types (and string) for use as dictionary keys. Today we will see how custom types fare. Let’s start with a custom value type which simply wraps a string: We’ll use a…
TKey performance indicators: primitives
Recently I encountered a situation where a seemingly innocuous change in the structure of a dictionary key had a noticeable negative performance impact (more on this later). This got me thinking, how exactly do different types of keys measure up…
An even faster hash table
Last week, in my continuing exploration of a C++ Letter Boxed solver, I had to build a faster hash table to improve performance. Today we’ll make it even faster, hoping to catch up to the performance of my .NET Core…
A faster hash table
Last time, I wrote about a native C++ implementation of the Letter Boxed solver. Vexingly, this native implementation was actually slower than the corresponding .NET Core app. Today we’ll try to fix that. As I mentioned, some basic profiling revealed…
Native code: always faster?
Last month, I explored some performance optimizations for a C# Letter Boxed solver. It was a fair bit of effort but in the end I could solve a typical puzzle in ~80 ms. Success! However, you might rightly point out…