Anyone concerned about .NET memory requirements?
Having only developed non-performance critical applications on PCs (but coming from an MVS Systems Programming background) I've never cared too much about process memory usage.
However, one of the slightly-up-his-own-arse DBAs at the place I'm currently contracting has whinged about the memory usage of a pilot VB6 inventory management product that I've designed and helped develop. I think it uses about 15Mb. Standard desktop there is NT4.0 64Mb+ of physical memory. It's a fair observation.. some (presumably C/C++) applications of a similar complexity survive with less than a meg of working storage.
Do I care? Nope. Has anyone actually recorded a problem as a result? Nope.
BUT! Now I'm developing this application's big commercial brother in .NET and VB6 has *nothing* on .NET for memory usage!!
Whilst it still doesn't cause me any problems I can't help wondering if customers out there are going to balk at applications that have large memory requirements?
The trend seems to be to assume that we have infinite computing and network resources these days. People seem perfectly happy to use XML to exchange data when actually it's horrendously inefficient in terms of data (a web service wanting to return a dozen bytes actually has to return 350+ bytes of XML data). Appropriate in some places.. definitely, but for passing table data around? and having a zillion repeated tags? Hmmm. I'm not so sure.
That last bit was slightly off track, my real point was to canvass opinion on the .NET memory issue
Tuesday, January 7, 2003
The adoption rate of .NET for business apps will probably be slow enough for the hardware in the entry-level business machine to catch up.
15MB is NOT a lot of RAM for a program. Just looking at my task manager, I've got IE using 18MB and Outlook using 12MB. Sounds like your employer needs to upgrade hardware.
I'm developing a shrink-wrap VB.NET app for business, and I'm not at all concerned about memory. We're not doing anything to require an extraordinary amount of RAM, nor will the app do high volume.
Also, we're only going to support the app on 2000/XP. If a potential customer is still running Win9x/NT4 it's obvious they don't view their computers as serious tools. Hell, even Microsoft doesn't support those two anymore. Long term we'd end up losing money on them through the increased support costs.
You've got to be lovin' that contract you're on. Shoehorn a .NET app into an NT4 desktop with 64MB RAM? On an hourly rate? You could lower your rate to get some good PR and still make out like a bandit!
Friday, January 10, 2003
Be careful what you're measuring. Is it the working set or the actual memory? If it's the working set, here's a link on how to reduce this
And whether this trick reduces performance
Hope this helps.
Saturday, January 11, 2003
The thing is, the choices come down to:
Go to Fry's and spend $100 for an extra 256 megs of ram (or is it 512 megs these days?)
Spend engineering time at $40-$100 an hour to get the app to fit into smaller memory.
The tradeoff point fairly quickly favors just buying more RAM. I wouldn't worry about it.
Sunday, January 12, 2003
Where is the memory usage figure coming from? Because of the way the virtual memory system works it is not really meaningful to look at the memory usage figures in the task manager. It certainly has little to do with the amount of physical ram the system has, since that is effectively used as a cache for pages from the swap file and dll/exe files that are mapped into memory. If the app runds fine on that system, that is all you need to be concerned about.
Tuesday, January 14, 2003
Your calculations are OK, when you are dealing with 1-10 computers.
Multiply it by 1000 computers in 50 departments, add a time and resources needed for an upgrade process and the proportions will be inversed.
I think every software producer should be very carefull with assumptions like: "Nowadays everybody has P4 with 512MB RAM". No, not everybody. And very often it is not a question of money.
Though, I think, developping new software for .NET we can assume the hardware is "strong enough". If the new software is worth of the change, hardware upgrade will be probably less problematic than upgrading software. But, is it really worth of it ?
Tuesday, January 14, 2003
Take a look at this article
Sunday, January 19, 2003
Exactly how do I do this API-call in C#-code?
Tuesday, September 7, 2004
Fog Creek Home