概览
我在通过计算器类迭代多次时遇到性能下降。
迭代次数增加时，每次迭代大约需要300万次，并且随着迭代次数的增加需要更长时间（30％+ /每个进程）。我必须停止程序/重新启动我执行的操作才能恢复正常状态（每个进程300万次）。
我做什么
我有一个科学的应用程序，测试一个过程的一组参数。
例如，我有N个场景（即参数组合），在实验集上进行测试，它包含一个计算器类，它接受输入中的参数，根据T可能的XP条件处理它们，并将输出存储在ORM对象中，即每次迭代后都会向DB激发。
换句话说，每个N参数组合都通过计算器传递T次。
Parameter combination : Params Set 1, Params Set 2, ...., Params Set N
Experimental Set : XP Set 1 , XP Set 2 , ...., XP Set T
所以我有NxT组合，N和T各约256个，可以进行65000次迭代。
我是怎么做的
我有一个GUI来修复参数集，并启动后台工作程序（每个参数组合一个）。每个Backrgound工作程序加载第一个T XP集，执行当前参数集，移动到下一个XP集，依此类推。计算器在每次迭代后生成一个报告（即在每个Nx / Tx之后）并触发一个事件以填充.NET Linq / SQL ORM对象（AgileFX）并将它们存储到SQL Server数据库中。
问题
这个过程在前30分钟运行良好，然后慢慢开始漂移，每次迭代花费的时间越来越长（声音就像内存溢出一样......）
HINT
奇怪的是，一位实验者非常有针对性地注意到 处理时间以线性方式增长 ：比先前处理时间多出3百万。归结为算术级数（Tn + 1 = Tn + 3mn）
我有一个12核INTEL和24GB RAM
答案 0 :(得分：1)
快速建议，您是否可以通过Memoization解决问题，避免重新计算应该知道的结果？
另外，请记住，如果你的垃圾收集器将以某种方式找到对象的引用，你的垃圾收集器将无法进行垃圾收集！
答案 1 :(得分：1)
我认为我找到了问题的一部分，但它没有完全解决问题：
通过监听器注册的代理发送到ORM的对象，因此每个计算线程在内存中仍然“存在”，即使它已经结束。 正如一位同事所说的那样：“即使你离开了，如果我的寄存器里仍然有你的地址，那我就还住在附近。”
BTW，VS2010中的性能向导是一种享受。非常有见地，有助于精确和准确地监控整体内存性能。 编辑：问题已解决
负责解雇后台工作人员的班级正在跟踪跟踪器对象中的一些数据，这些数据一直在不断增长，从不刷新，变得越来越大。通过密切跟踪VS 2010性能向导中每个对象的内存使用情况，我注意到了这一点
我建议清楚地了解对象的生命周期和内存使用情况，尽管当应用程序庞大而复杂时它会变得很难。