.NET Memory Performance Analysis | Hacker News Reader

.NET Memory Performance Analysis

github.com

226 pointsrbanffy39 comments

She has some video's on her YouTube channel about this topic as well: https://www.youtube.com/channel/UCk1EXxUVEKnPNV5gTAijSZg (cat included)

I don't think they were linked from the document on github.

Very detailed list of recommandations.

Do they apply to other Garbage-collection-based languages?

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.

In particular as far as I know .NET's decision to segment things into 3 generations is pretty unusual.

Looks broadly identical to JVM generations. Gen0 = eden space, Gen1 = survivor space, Gen2 = old gen (think they're calling it tenured now lol).

Unless I'm creatively remembering, Dave Moon's EGC (Ephemeral Garbage Collector) in Symbolics Genera in 1985(?) had three generations.

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.)

Pretty sure this is the person who is one of the architects on the Garbage Collector in NET.

And a very good at it.

I'm in no way questioning their expertise; I am simply asking if there's a step that comes before this document.

https://github.com/Maoni0/mem-doc/blob/master/doc/.NETMemory... probably answers your question.

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.

If you read one person about dotnet, this is the person. If you read two, include David Fowler.

There's a lot of great people in the .NET ecosystem, but I don't think GC internals are that relevant for most typical .NET devs.

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.

There is a version for UWP as well.

Really? What’s it called?

Similarly named, Windows Runtime via C#.

https://www.amazon.com/Windows-Runtime-via-Developer-Referen...

Neat! I would definitely like a .NET Core version, though. I was disappointed to discover netmodules were deprecated

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.

You're selling Eric Lippert too short

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.

Jon Skeet, Mark Seemann, Jeff Richter too

Stephen Toub!

Many more great .NET folks to follow on this list as well.

https://twitter.com/i/lists/120961876

I worked with David Fowler he’s really good.

Matt Warren writes a lot of nice stuff about .NET internals and performance.

If you read one person about .Net GC performance - Maoni is that person.

If you read three, include Stephen Toub

Why?

>https://github.com/dotnet/runtime/graphs/contributors

Four, include Marc Gravell.

https://blog.marcgravell.com/

I recomend this book: https://www.apress.com/gp/book/9781484240267

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."

It's the first and last time I've used them.

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

https://www.amazon.co.uk/gp/aw/d/148424026X/ref=dbs_a_w_dp_1... Btw its 1100pages long!

Any suggestions for an equivalent for Java?

Reply on news.ycombinator.com