The last pearl of design that I covered was an implementation for the discriminated union in the probuf-net library. Now, it's time to move to an area that is less esoteric in terms of the format, but still intriguing in terms of performance. Time to take a look at the fastest JSON serializer available for … Continue reading Pearls: Jil, serialization of primitives
Optimization
Pearls: the protobuf’s discriminated union
Google Protocol Buffers is a proven protocol for serializing data efficiently. It has a wide adoption, enabling serialization for almost every platform, making the data easy to exchange between platforms. To store its schema, you can use .proto files, that enable describing messages in a platform agnostic format. You can see an example below: message … Continue reading Pearls: the protobuf’s discriminated union
Performance matters
This is a follow-up post about Marten's performance. It shows that saved allocations are not only about allocations and memory. It's also about you CPU ticks, hence the speed of your library.
.NET volatile write performance degradation in x86
TL;DR This is a summary of my investigation about writing a fast and well designed concurrent queue for akka.net which performance was drastically low for 32bit application. Take a look at PR here. If you're interested in writing a well performing no-alloc applications with mechanical symapthy in mind or you're simply interested in good .NET … Continue reading .NET volatile write performance degradation in x86
Roslyn coding conventions applied
Roslyn is a 'compiler as a service' provided for both VisualBasic.NET & C#. It has a thriving community of people providing new features for .NET languages. One of the most important parts of this community is a guideline how to contribute, which defines basic rules for coding and issuing pull requests. The most important part, … Continue reading Roslyn coding conventions applied
False sharing is dead, long live the Padded
False sharing is a common problem of multithreaded applications in .NET. If you allocate objects in/for different threads, they may land on the same cache line impacting the performance, limiting gains from scaling your app on a single machine. Unfortunately, because of the multithreaded nature of the RampUp library it's been suffering from the same … Continue reading False sharing is dead, long live the Padded
StructLayoutKind.Sequential not
If you want to write a performant multi threaded application which actually is an aim of RampUp, you have to deal with padding. The gains can be pretty big, considering that the whole work with threads mean, that you need to give them their own spaces to work in. False sharing False sharing is nothing … Continue reading StructLayoutKind.Sequential not
