TL;DR: Micro-optimizations are not a substitute for design work. They are how you earn the right to redesign. In the Azure Service Bus SDK, repeated work in the Body property first led to smaller allocation fixes. Once those fixes exposed the shape of the problem, a small internal redesign made the code faster, clearer, and easier to reason about. “This code is bad. We should rewrite it.” Most developers have heard that sentence. Many have said it. I have too. The problem is not...
TL;DR: After temporary allocations were removed from the Azure Event Hubs partition-key encoding path, the Jenkins lookup3 hash loop itself became the next interesting place to look. Tightening that loop reduced CPU overhead, but it also raised the bar for review, portability, and correctness. I like performance work most when it starts with a boring question: why is this small method showing up so much? That question came up while looking at the Azure Event Hubs client. Event Hubs is built for...
TL;DR: Small code paths become expensive when cloud workloads execute them millions of times. The Azure Event Hubs partition key resolver is one of those paths. By removing temporary allocations from the partition-key encoding path, the Azure Event Hubs SDK reduced garbage collection pressure on a publishing hot path. I like performance work most when it starts with a boring question: why is this small method showing up so much? That question came up while looking at the Azure Event Hubs client...
In the last post about the MPCC I explained how the asynchronous synchronization works by leveraging the power of a TaskCompletionSource. Today I’ll walk you through the completion method. The completion method has essentially two modes. A drain mode and a non-drain mode. In the drain mode, all items that are enqueued will be asynchronously pushed until all internal queues are empty. In the non-drain mode, the queues will be emptied but nothing will be pushed if there is something left...
In the last post I explained how the push in batches up to the concurrency per slot works. This post covers the asynchronous synchronisation approach I used to unleash the push in batches when the batch size is reached. In the code shown in the Push It post I simplified the synchronisation primitive and called it syncEvent. In reality, the code uses a TaskCompletionSource for synchronisation. The MPCC declares a field of type TaskCompletionSource<bool>. For the MPCC the TResult type of...
In the previous post I introduced the PushInBatches method who’s responsibility it is to start the PushInBatchesUpToConcurrencyPerQueueForAGivenSlot process. In this post I will focus on the mouthful method above. Like the name of the method already suggest its responsibility is to push items for a slot in batches to the pump delegate while respecting the concurrency settings per slot as provided by the user and explained in the introduction post. Without further ado here is the whole...
In the last post, I introduced the push method and the timer loop of the MultiProducerConcurrentConsumer. In this post, I’ll focus on the actual PushInBatches method that gets called by the timer loop. When the method is entered it first checks whether there is anything to push. Since numberOfPushedItems is accessed by multiple threads it uses Interlocked to read it and compare the returned value. When there is nothing to push a completed task is return. By not using the async keyword...
In the last post, I introduced the start procedure for the MultiProducerConcurrentConsumer including a rough outline of the timer loop responsible for pushing items in batches after the push interval is elapsed. To understand how the batch size affects the push let me first explain the push method. The push method’s responsibility is primarily to insert the item of type TItem into the right slot. To achieve that the passed in slot number is range checked against the available number of...
In the previous instalment, we discussed the technique of preallocating and reuse to save allocations during runtime. In this post, I will introduce the heart of the MPCC which is the start method and the timer loop outline. The MPCC can get started at any time after construction. If the component is started, it will start pushing items to the pump delegate whenever the batch size is reached or the push interval. This is how the Start method looks like The MPCC can be started once only. There...
In the last post, I introduced the MultiProducerConcurrentConsumer component. In this post, I’m going to walk through the constructor of the component and explain the preallocation trade-off that was made. With almost every code that is executed on the hot path of your library, framework or system you need to make tradeoffs regarding allocations. In the end, it boils down to roughly two choices: Allocate as much as you need upfront Allocate on-demand when you need it The benefit of only...