我正在研究蒙特卡罗定价器，我需要提高引擎的效率。
- MonteCarlo 路径由第三方库(在 c++ 中)创建
- 定价在 IronPython 中完成(由最终用户创建的脚本)
- 其他一切都由 C# 应用程序驱动
定价过程如下:
- C#应用程序请求路径并收集它们
- C# 应用程序将路径推送到脚本，脚本定价并返回值
- C# 应用程序向最终用户显示结果
收集的路径的数量和大小是预先知道的。
我有 2 个解决方案，各有优缺点:
- 请求路径生成，对于每个路径，要求脚本返回结果，并在处理完所有路径后最终聚合结果
- 请求路径生成，收集所有路径，请求脚本一次处理所有路径并返回最终价格
第一个解决方案在所有情况下都运行良好，但随着请求路径数量的增加，性能下降(我认为这是由于对 ironpython 的多次调用)
第二种解决方案更快，但如果请求的路径数量太大，可能会遇到“内存不足”异常(我认为它没有足够的虚拟内存寻址空间)
我选择中间立场并处理一系列路径，然后汇总价格。 我现在想要的是通过提前知道我可以处理多少条路径而不会遇到“内存不足”异常来进一步提高性能
我做了数学计算，我提前知道给定请求的路径大小(在内存中)。但是，因为我很确定这不是内存问题，而是更多的虚拟内存寻址问题
所以所有这篇文章都是通过以下 2 个问题总结的:
- 有没有可能提前知道我的虚拟内存地址有多少 进程需要存储类的 n 个实例(内存大小和结构已知)？
- 是否有可能知道我的进程还有多少虚拟内存地址可用
顺便说一句，我在 32 位计算机上工作
在此先感谢您的帮助
最佳答案
找出一个对象在 .NET 中占用多少内存是一项相当困难的任务。我多次遇到同样的问题。有一些不完善的方法，但没有一个是非常精确的。
我的建议是估计一条路径需要多少时间，然后通过其中的一些，留下良好的安全边际。即使您一次只处理 10 个，您也已经减少了 10 倍的开销。
您甚至可以使边距可配置，然后对其进行调整，直到达到良好的平衡。一个更优雅的解决方案是在另一个进程中运行整个过程，如果它遇到 OutOfMemoryException，则用更少的项目重新开始计算(并相应地调整边距)。但是，如果您的数据太多以至于内存不足，那么跨两个进程传递它可能会有点慢(这也会复制数据)。
难道内存溢出是因为路径处理器的一些不完善？也许内存泄漏？这些在 C++ 和 .NET 中都是可能的。
关于c# - c#中的虚拟内存地址管理，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8257686/