SmartAssembly内存管理
刚刚发现此网站。 功能 9 是内存管理，他们声称他们的产品“自动释放不再需要的内存”。
这是一种营销策略，还是你认为他们有什么伎俩？ 他们是否只是根据 .Net 运行时在任何情况下提供的内容做出声明（或者他们是否喘息调用 GC.Collect()）？
我对这个产品并不是很感兴趣，DotFuscator 对我来说就足够了 - 我只是真正对如何实现这一点感兴趣。
Just came across this website. Feature 9 is memory management and they claim that their product "automatically releas[es] memory [that is] no longer needed."
Is this a marketing ploy, or do you think they have some trick up their sleeves? Are they just making a claim based on what they .Net runtime provides in any case (or are they gasp calling GC.Collect())?
Not really interested in the product, DotFuscator suffices for me - I am just really interested on how this could be achieved.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有趣的。
2007 年的评论包含以下内容：
同一篇评论有一对“之前/之后”屏幕截图，显示应用程序从 8M 变为 420K。 这对我来说意味着它实际上只是减少了应用程序的工作集，而不是真正的内存需求。 如果您最小化应用程序，也会出现相同的“优化”。 它不会突然占用更少的内存。 我不相信桌面 .NET 框架能够真正仅用 420K 运行。
自动密封功能很有趣 - 除了查找虚拟方法之外，我看不出它有什么帮助。 我怀疑影响是否真的显着，但当然我还没有对其进行基准测试。
所以，没有什么结论，但我怀疑它是否做了我特别想要的事情。
Interesting.
A review from 2007 contains this:
The same review has a "before/after" pair of screenshots showing an application going from 8M to 420K. This suggests to me that it's actually just reducing the working set of the application, not the real memory requirements. The same "optimisation" appears to occur if you minimise an app. It doesn't suddenly take up less memory. I don't believe the desktop .NET framework can really run with only 420K.
The automatic sealing feature is interesting - I can't see that it helps other than for lookup of virtual methods. I doubt that the impact is really significant, but of course I haven't benchmarked it.
So, nothing conclusive, but I doubt that it's doing anything that I'd particularly want.
我可能是错的，但在我看来，SmartAssembly 将数据推送到页面文件。 如果在任务管理器中选择 CommitSize 和 PF delta 列，您将看到虽然工作集减小了大小，但提交大小几乎保持不变。 如果您随后尝试访问应用程序中的某些内容，您将看到大量页面错误。
如果这是“内存优化”的行为，那么我认为该名称不适合该功能，它应该简单地称为“去优化”，因为访问页面文件的成本可能会显着降低性能。
我这个解释有错吗？
I may be wrong, but it seems to me that SmartAssembly pushes the data to page file. If in task manager you select the columns CommitSize and PF delta you will see that although the WorkingSet reduces size, the commit size stays almost the same. If you then try to access something in your application you will see lots of page faults.
If this is the behavior of "Memory optimization" then I think the name does not fit the feature and it should simply be called "De-optimization" as the cost of accessing the page file could significantly reduce performance.
Am I wrong with this interpretation?