Tag: Development

Here’s a story on how I once used dotPeek to provide debugger symbols and (decompiled) source code for a crashed application for which we had nothing but the application assemblies available. Namespaces have been altered to protect the innocent.

Two weeks ago I had a wonderful experience speaking at a small conference in Finland. The talk was titled What is going on - Application diagnostics on Azure (slides) and focused on the importance of semantic logging and how Azure Application Insights (AppInsights) can help make sense of that data and correlate it with other telemetry coming from the application server. What I did not cover in that talk was AppInsights telemetry processors - essentially a pipeline through which your server-side AppInsights data passes before it is sent off to the giant data store that is the AppInsights service.

Since my posts on making code allocate less memory and memory allocation for strings were quite well received, I decided to add another post to the series: Exploring .NET managed heap with ClrMD. In this post, we’ll explore what is inside .NET’s managed heap (you know, the thing where we alocate our objects), how it’s structured and how we can do some cool tricks with it. We’ll even replicate dotMemory’s dominators/path to root feature.

A while back, I wrote about making code allocate less memory (go read it now if you haven’t). In that post, we saw how the Garbage Collector works and how it decides to keep objects around in memory or reclaim them. There’s one specific type we never touched on in that post: strings. Why would we? They look like value types, so they aren’t subject to Garbage Collection, right? Well… Wrong. Strings are objects like any other object and follow the same rules. In this post, we will look at how they behave in terms of memory allocation. Let’s see what that means. In this series:

The .NET Garbage Collector (GC) is quite cool. In combination with the runtime’s virtual memory, it helps providing our applications with virtually unlimited memory, by reclaiming memory that is no longer in use and making it available to our code again. By doing so, it also takes away the burden of having to allocate and free memory explicitly. But sometimes, it still matters to understand when and where memory is allocated. The reason for that is simple: if we can use efficient coding to help our GC spend less CPU time allocating and freeing memory we can make our applications faster and less “allocatey”.