The article is quite specific to the .Net garbage collector. Only some of the most general concepts touched on in the introductory sections apply to other garbage collected languages.
Honest question here - does this document start at a point where you've already done some analysis, and decided that memory is your bottleneck, and memory profiling and optimisation is the way you want to go? Or is a generally accepted best practice to first do this anyways, and then move on to e.g. CPU profiling, regardless of being say CPU-bound? I've only skimmed the document, intending to read it later, but didn't see an answer to this. Where can I find more info?
(I'm asking as someone who has done a fair bit of "performance work" but strictly at a higher level - by selecting more appropriate algorithms for the nature and size of data, minimising time spent waiting for network calls, etc, so it's rare that I have to dive very deeply in to "proper" performance work. But, I would like to learn more.)
Ah, excellent, thanks. I think this part is quite clear, also clarifying my related question, which is what the scope of this document would be:
> When the relevant GC metrics says GC is having a small effect, it would be more productive to focus your effort elsewhere. If they indicate GC does have a big impact, this is when you should start worrying about how to do managed memory analysis, which is what the majority of this doc is about.
Typically, you're right - GC internals aren't usually relevant. That is, until you're fire-fighting a GC-related issue in production. GC internals aren't something you want do a crash-course on while your app burns.
I'd call it a good sign if you can even identify GC-related issues in production. That means all of the other problems that seem to plague .NET shops have been taken care of.
It's always a captivating read for me! I find most discussions about the tradeoffs of GC vs reference counting versus manual memory management are loaded with bias.
There’s definitely more there than most .NET devs need to know, but I personally have found learning more about the GC to be incredibly relevant in my day to day work. I would have said the same thing a year ago, now I feel differently, but that is of course heavily inflected by my personal experience.
Similarly you might not expect that reading CLR via C# would make you a better programmer at a high level with things like DI and big frameworks and everything, but it makes you see what you're writing in an entirely different light. A whole other layer below the surface.
I would strongly second that endorsement. I would love a new edition taking the CoreCLR more into account but it’s still more relevant than most any other book I can think of.
Just offering my personal opinions (by which I mean biases), Eric is also great. Andrew Lock and Steve Gordon are also great choices. Personally, I prefer nuts and bolts .NET writers since there is so much (and much of it good!) DDD/SOLID type content out there.
Last I used Apress, after placing the order they had writing at the bottom of the order confirmed page to the effect of:
"We didn't ask for your permission, but regardless we've added you to our marketing email list and the only way to unsubscribe is to contact our customer service team."
Never mind the Apress, the book is also available or Amazon or other bookstores. The material that this book covers is very impressive and the author knowledge even more, he has some of his womrshops/conference speaches available on yt
I don't think they were linked from the document on github.