This is an open question really for people that make, use, or host ASP.NET apps… When you’re choosing a technology stack how important are memory pressure concerns?

So if you’re looking at adding automapper, or nhiberbate, or ioc xyz, you’re obviously going to be thinking about impact to CPU and memory.

And there are two type of memory impacts: load-and-hold and burn-rate (or memory pressure). The first is relatively easy to say you’re using ten megs of one-time cost memory in each appdomain once it’s initialized and warmed up. The other’s a bit more subtle - if a tool goes through a two megs of object, string, collection, buffer memory in a request - and say you’re tooling along with bursts of 25 req/sec - then 50meg/sec means you’ve given the garbage collector a gig of ram to recycle every 20 seconds. Numbers and needs vary but you get the idea that high burn rates end up causing a CPU tax to be paid affecting the net power availabe.

But on the other hand dotnet is a high level language, and a lot of there types of things are developer productivity tools - not performance tool - so they will *always* have measurable increase in cost. But in the most extreme cases, like from he point of view of a hosting company, you could almost assume that memory efficiency is directly proportional to hardware, space, and power costs per client…

Not that it’s a black and white situation, of course, but at what point are the conveniences and strengths of a library outweighed by the cost of using it? Of course it’s always difficult to weigh something subjective against something quantifiable.

But what’s your take on that?