or subscribe with
Join 19,300+ readers for one email each week.
Digests » 304
Vettery is an online hiring marketplace that's changing the way people hire and get hired. Ready for a bold career move? Make a free profile, name your salary, and connect with hiring managers from top employers today.
this week's favorite
C# 7.2 added support for ref struct types, and as I’ve discussed before, these are critical to achieving high throughput in certain kinds of code by minimizing GC overhead and copying. But you pay a price in flexibility. In that last article, I showed how to work around the fact that you cannot use a ref struct inside an async method. In this article I’ll discuss an issue we ran into when writing tests for the Ais.Net parser I recently blogged about.
Compared to other languages, C# was way behind in capabilities to handle data efficiently. Well, those days are over now. Microsoft just improved the C# syntax, making it easier for developers to manage data in arrays.
NoAlloq aims to provide basic LINQ functionality on top of Span<T>, without allocating any memory. Since some LINQ features (such as .Reverse() or .OrderBy()) require storing the entire sequence in memory, NoAlloq requires the user to provide their own memory backing.
With an integration test, we test the API from the outside out by spinning up the API client and making an actual HTTP request. I get confidence out of it because I mock as little as possible, and I will consume my API in the same way as an application (or user) would.
In practice, obviously I’ve exaggerated the ease with which a codebase can be made fully asynchronous, and as with many a software development task, the devil is often in the details. One such “devil” that performance-minded .NET developers are likely familiar with is the state machine object that enables an async method to perform its magic.