I’ve been reading the excellent Technically Speaking newsletter for a while now and when they announced they would be running a mentoring program, I jumped at the chance and applied straight away. The idea was that each applicant had to set themselves speaking goals or identify areas they wanted to improve and then if you were selected @techspeakdigest would set you up with a mentor.
This series is an attempt to learn more about how a real-life “Garbage Collector” (GC) works internally, i.e. not so much “what it does”, but “how it does it” at a low-level. I will be mostly be concentrating on the .NET GC, because I’m a .NET developer and also because it’s recently been Open Sourced so we can actually look at the code.
In the previous post I looked at the community involvement in the year since Microsoft open-sourced large parts of the .NET framework.
A little over a year ago Microsoft announced that they were open sourcing large parts of the .NET framework. At the time Scott Hanselman did a nice analysis of the source, using Microsoft Power BI. Inspired by this and now that a year has passed, I wanted to try and answer the question:
This is the part 3 of a mini-series looking at what it might take to build the Stack Overflow Tag Engine, if you haven’t read part 1 or part 2, I recommend reading them first.
This is the long-delayed part 2 of a mini-series looking at what it might take to build the Stack Overflow Tag Engine
I first heard about the Stack Overflow Tag engine of doom when I read about their battle with the .NET Garbage Collector. If you haven't heard of it before I recommend reading the previous links and then this interesting case-study on technical debt.
In Part 1 I looked at some of the more general performance issues that can be learnt from Stack Overflow (the team/product), in Part 2 I’m looking at some of the examples of coding performance lessons.
This post is part of a semi-regular series, you can find the other entries here and here