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…
Letter Boxed: perf gains and losses
After successfully optimizing the trie loading path, we apparently “pessimized” the solution path. Let’s see if we can find out why. I’ll start by building a benchmark for the word finding algorithm: FindWords benchmark Note that this benchmark eliminates all…
Letter Boxed: optimizing the trie
Last time, I demonstrated a relatively fast Letter Boxed solver. It took about 15 ms to solve the puzzle, but that was after a delay of over 200 ms while loading the trie. Surely we can squeeze some more performance…