@khalidabuhakmeh I see you are getting a whole lot of sophisticated suggestions. I am here for the more fundamental issues I see. e.g. Don't use ReadAsStringAsync and then Deserialize<T>(string)
@khalidabuhakmeh inspired by this "back to basics" tip: don't call ToList/ToArray blindly everywhere, creating a crap ton of collection copies.
For example when R#/Rider warns about possible multiple enumerations of an IEnumerable, folks response to it is adding a ToList/ToArray in there, very likely, unnecessarily.
Sorry about that, I should have been clear to my reasoning. Also note, a while back @davidfowl had a great insight on this topic about the fact that if the response size was more than 80K then that string would end up on the large object heap. It doesn't take much to make 80KB of JSON payload.
@khalidabuhakmeh
Concepts wise:
GC phases
Large Object Heap
Events raised by the GC system
Memory dumps
Bonus points if I'm interviewing someone and they mention the GC card table (although I've never really found a use for that knowledge).
Watch out for Linq / Closures burning memory.
@khalidabuhakmeh Honestly, I’ve been a .NET developer for over 8 years and I’ve never been taught to (or felt a compelling need to) think hard about memory, aside from some occasional dispose patterns. Sometimes I come back to this topic and feel like I’m missing a big chunk of important things.
@khalidabuhakmeh got opinions, but it varies greatly on type of app, mostly on how long process is running, a console app and just runs and dies less worried about memory management. Strategies varies based on how many instances per "user" too, i.e. one instance serving many over time can cache things more aggressively, whereas cache less beneficial for many instances serving few.
But in general the fewer objects you new up, the less memory you use.
Add comment