什么构成了良好的内存配置文件？
在设计任何桌面应用程序时，是否有关于应用程序应使用多少内存的一般规则？
对于重量级应用程序，这些应用程序可以轻松理解或至少进行分析，例如 Firefox 或 Google Chrome。 但对于较小的实用程序或业务线应用程序，可接受的内存使用量是多少？
我问这个问题是因为我最近遇到了内存使用和性能之间的权衡，想知道对此是否有任何普遍共识？
编辑：平台是Windows XP，适合机器只能运行富互联网应用程序的用户。
我的具体权衡问题是在内存中缓存大量图像。 如果可能的话，我希望在用户内存允许的情况下拥有尽可能多的应用程序缓存。 我这样做是为了使应用程序能够缓存到某个最大限制考虑到当前的内存压力。。
但什么数字才算好呢？ 你怎么想出一个？ 这就是我要问的重点。
In designing any desktop applications, are there any general rules on how much memory should the application uses?
For heavy-weight applications, those can be easily understood or at least profiled such as Firefox or Google Chrome. But for smaller utilities or line-of-business application, how much is an acceptable amount of memory usage?
I asked because I've recently come across a trade-off between memory usage and performance and wonder if there is any general consensus regarding it?
EDIT: Platform is Windows XP for users with machine just capable of running rich internet applications.
My specific trade-off problem is about caching a lot of images in memory. If possible, I'd love to have my app cache as much as the user's memory will allow. I have done it so that the application will cache upto a certain maximum limit considering memory pressure at the moment..
But what would be a good number? How do you come up with one? That's the point I'm asking.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对此没有绝对的答案。 这取决于太多的变量。
以下是一些需要考虑的权衡：
有时，鱼与熊掌兼得是可能的。 例如，如果您正在读取一个文件并将其写回，则可以逐块读取它，而不是将整个文件读入内存然后将其写出。 在这种情况下，您可以更好地使用内存，并且速度不会降低。
如果必须的话，我通常建议使用更多的 RAM 以获得更好的速度。 但前提是 RAM 要求对于您的目标受众来说是现实的。 例如，如果您希望拥有 1GB RAM 的家庭用户使用您的程序，那么您自己就不要使用 600MB RAM。
请考虑在此实例中使用更多 RAM 以获得更好的速度，并优化代码的其他部分以使用更少的 RAM。
编辑：
关于您缓存图像的具体情况。 我认为最好允许用户设置他们想要执行的缓存量作为一个选项。 这样，拥有大量内存的人可以将其设置得更高以获得更好的性能，而拥有少量内存的人可以将其设置得较低。
There is no absolute answer for this. It depends on too many variables.
Here are some trade-offs for consideration:
Sometimes it's possible to have your cake and eat it too. For example if you were reading a file and writing it back out, you could read it chunk by chunk instead of reading the whole file into memory and then writing it out. In this case you have better memory usage, and no speed decrease.
I would generally recommend to use more RAM to get better speed if you must. But only if the RAM requirements are realistic for your target audience. For example if you expect a home user that has 1GB of RAM to use your program, then don't use 600MB of RAM yourself.
Consider using more RAM in this instance to get better speed, and to optimize some other part of your code to use less RAM.
Edit:
About your specific situation of caching images. I think it would be best for you to allow the user to set the amount of caching they would like to perform as an option. That way people with a lot of RAM can put it higher for better performance, and the people with little RAM can set it low.
这完全取决于您的目标平台，这或多或少是一个业务决策。 您需要的内存越多，能够使用您的软件的客户就越少。 要问的一些问题：您的客户（或潜在客户）在他们的计算机中安装了多少内存？ 它们还会与您的应用程序同时运行哪些其他应用程序？ 您的应用程序是否被假定为专门运行（例如全屏计算机游戏），或者是一个应该主要在后台运行的实用程序，或者经常从其他应用程序切换到它？
Hear 是一项调查示例，显示通过 Steam 玩游戏的人们系统中已安装 RAM 的分布情况（来源：Valve - 调查摘要数据)：
我从我的领域（电脑游戏）中的此类调查中得出的结论是，我可以合理地预期几乎所有用户都拥有 512 MB 或更多，并且绝大多数拥有 1 GB 或更多。 对于一款应该独占运行的电脑游戏来说，这意味着 400 MB 左右的工作集相当安全，几乎不会限制任何人退出，如果它为产品提供了显着的附加值，那么拥有一个工作集可能是有意义的大约 800 MB。
This depends entirely on your target platform, which is more or less a business decision. The more memory you will need, the less customers will be able to use your software. Some questions to ask: How much memory do your customers (or potential customers) have installed in their computers? What other applications will they run simultaneously with your application? Is your application something assumed to be running exclusively (like a full screen computer game), or a utility which is supposed to run mostly in background, or to be switched into it from other applications often?
Hear is one example of a survey showing a distribution of installed RAM in systems of people playing games via Steam (source: Valve - Survey Summary Data):
A conclusion I would draw from a survey like this in my domain (computer games) is I can reasonably expect almost all our users having 512 MB or more, and vast majority having 1 GB or more. For a computer game which is supposed to run exclusive this means working set around 400 MB is rather safe and will limit almost no one out, and if it provides a significant added value for the product, it may have a sense to have a working set around 800 MB.
这取决于您的目标 PC 硬件。 如果您的应用程序使用太多内存，那么 Windows 页面加载时速度会很慢。 测试！ 在你的妥协中尝试这两种选择，如果有意义的话，可以尝试一些介于两者之间的选择。 在用户将使用的典型计算机上运行测试，并打开大量其他应用程序。 因此，对于大多数人来说，这就是 Outlook，可能还有一个或两个 Internet Explorer（或您选择的邮件客户端/浏览器）。 我在一个组织中工作，我的应用程序的使用也可能正在运行一些其他自定义应用程序，因此我们也对正在运行的应用程序进行测试。 我们发现我们的应用程序使用了太多内存，并且使得切换应用程序非常缓慢，因此我们稍微减慢了应用程序的速度以减少其内存使用量。
如果您感兴趣，我们的目标硬件最初是 512Mb 机器，因为那是我们常见的标准规格工作站。 但由于此应用程序，一些 PC 必须升级到 1Gb。 我们现在已经稍微削减了它的 RAM 使用量，但它是用 VB .NET 编写的，并且使用的大部分内存似乎都是框架。 PerfMon 表示该进程使用了大约 200Mb（峰值），但托管堆只有大约 2Mb！
This depends on your target PC hardware. If your application uses too much memory then it will be slow while windows pages. TEST! Try both options in your compromise, and some in between if it makes sense. Run the tests on a typical machine that your users would use and with a sensible number of other applications open. So for most people that is Outlook and probably an instance or 2 of Internet Explorer (or the mail client/browser of your choice). I work in an organistion where uses of my application are also likely to be running some other custom applications so we test with those running as well. We have found that our application used too much memory, and makes switching application painfully slow so we have slowed our application slightly to reduce its memory usage.
If you are interested our target hardware was originally 512Mb machines becuase that was what our common standard spec workstation was. Several PC's had to be upgraded to 1Gb though becuase of this application. We have now trimmed its RAM usage a bit but it is written in VB .NET and most of the memory used seems to be the framework. PerfMon says the process is using aroung 200Mb (peak) but that the managed heap is only around 2Mb!