我开始在我的生命中第一次用C＃编写一个大型应用程序。我编写了示例模块来测试我的软件背后的想法。该模块包含几十个C＃字典和对象列表，每个对象都有几个成员和属性。
我很震惊，在初始化核心对象后，它最终使用了大约40MB的RAM。
我测试并发现在对象初始化之后分配了超过30MB，但我的印象是，考虑到我的对象的大小，应该消耗不超过几百千字节。
与本机代码应用程序相比，我做错了什么或者.NET本身是内存密集型的吗？
答案 0 :(得分：12)
您是如何确定使用了多少内存的？众所周知，.NET应用程序急切地保留了比他们需要的内存更多的内存，只要有足够的可用内存，并且如果内存开始不足就会将内存释放回系统。
我想你可能会在this MSDN article中找到一些指示。
答案 1 :(得分：7)
使用任务管理器查看内存使用情况可能非常不准确。
相反，抓住一个合适的内存分析工具（dotTrace非常好，并且有10天的试用期）并花些时间来查看实际的内存消耗。
我在自己的代码中看到过的各种各样的事情包括
答案 2 :(得分：5)
在我们在一台机器上有几GB RAM的日子里，像你这样一个面向用户的应用程序通常用C＃构建的应该只使用几百克的ram是倒退的。系统上任何未使用的ram都会被浪费。
考虑到这一点，C＃使用与C ++完全不同的策略来分配内存，这样就可以更少地分配和释放更大的块。
那说，40似乎有点高。对于非常简单的控制台应用程序，我已经习惯了接近10-14Mb的东西。也许有一个形式占用ram，或者我可能使用不同版本的框架（2.0）。
答案 3 :(得分：2)
并不总是关于语言，通常是关于它的使用方式。
优秀代码可以在任何语言中有效地使用内存。
错误代码会在每种语言中低效使用内存
答案 4 :(得分：2)
.Net运行时有一定的开销 - 我们发现即使是简单的应用程序也会使用比用C ++编写的类似应用程序更多的内存。幸运的是，随着整体代码的大小增加，这种开销很快就会在噪声中消失。第二个因素是垃圾收集，垃圾收集器“随时”运行，因此与C ++相比，内存分配通常不会立即释放，而是在感觉需要这样做时。
答案 5 :(得分：2)
我会说，除非你有一个非常充分的理由担心RAM的使用，不要。像优化一样，你应该只优化有优势的地方客户/最终用户需要这样做。我不相信用户现在受到内存的限制（除非你在谈论嵌入式系统），他们会注意到或关心缺少38 MB的内存。
答案 6 :(得分：0)
如果您使用任务管理器查看内存，则可能会产生误导。工作集是映射到进程的虚拟内存量。不一定是您的应用程序使用了多少 - 在.NET的垃圾收集环境中尤其如此。当您的程序分配内存时，.NET CLR / GC通常会请求比实际需要的内存更多的内存，以便将来可以有效地将该内存分配给程序中的托管对象。
快速而肮脏的方式（非常脏）看看这是否影响到你是将Process.MaxWorkingSet属性设置为0.这类似于在Win32中使用SetProcessWorkingSetSize来尝试修剪数量映射到进程的页面。如果您立即看到内存使用量下降，那么您就知道发生了什么。但是，只要您通过GC / CLR再次开始分配内存，它就会恢复 - 通常这是一件好事。真的你不应该担心它，并让GC有机会以正确的方式做到这一点。
为了优化程序的内存使用情况并更好地了解内存分配在CLR中的工作方式，我建议你开始讨论dotTrace（我的偏好），Ants Profiler（偶然{{3} }}）。 publishes a cool video on this topic here也很有趣，但这些日子有点陈旧，但它是免费的。
答案 7 :(得分：-8)
做一个快速计算，你可能会分配大约340K的对象（减去32位上单个控制台应用程序通常的c12MB命中率，依旧史蒂夫！）并且看到[删除对每个对象吃8字节的典型场景的引用+然后其他一些用于其他对象通常的怀疑]运行时和System.Object浪费的参考类型由臃肿的运行时技术版权@ Sun.com ..
尽可能尝试和设计值类型/结构..如果你不能，那么强硬，告诉你的用户不要运行超过10个.NET应用程序，否则他们的机器会感觉比C64慢。如果它让你感觉更好，试试WPF或Silverlight，并为一些按钮和华丽的动画感受到c100MB的惩罚。
（downvote feel）