Renat: Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
窗户上的栏杆是多少钱？
问题是，当TF被切换时，终端中没有内存被释放出来。启动任务管理器，把指标 扔到图表上，看着内存的增长。然后切换到另一个TF，你会看到内存又开始增长。但从逻辑上讲，当你切换到另一个TF时，前一个TF的数据应该从内存中卸载。由于前一个TF的数据没有被删除，内存不断增长，直到它重新启动并产生错误。如果你把你的指标从图表上移开，你会看到在一定时间后，内存被清除。但在指标运行时，它不会被清除。
我的观点：解决这个问题的办法是ServiceDec。
谢谢，我将在切换TF之前先删除该指标。此外，我把窗口的最大条数从2000000减少到1000000，显然MetaDriver 想告诉我这一点。
到目前为止，它似乎是有效的。
谢谢，我将在切换TF之前先删除该指标。此外，我把窗口中的最大条数从2000000减少到1000000，显然MetaDriver 想告诉我这个。
到目前为止，它似乎是有效的。
你为什么需要10万？ 10万对我来说已经足够了。 这就是我想告诉你的。
它不以任何方式限制测试的深度。
它只限制了（1）窗口中的显示（2）指标缓冲区的大小。
我长期以来刻意限制 "可见的历史"。结果是--我在记忆方面没有问题。
你为什么需要一百万？ 10万对我来说已经足够了，这正是我所暗示的。
它不以任何方式限制测试的深度。
它只限制（1）窗口的显示（2）指标缓冲区的 大小。
我长期以来刻意限制 "可见的历史"。结果是，我的记忆力没有问题。
是的，谢谢，我准备在InstaForex公司更多的使用108个货币对，这样我就不会有任何记忆问题。
这是个很好的话题。早在MT5的早期，我就嚷嚷着所有指标都应该有一个新的标准 参数--计算的条数。
否则我们会得到唯一的限制器--TERMINAL_MAXBARS。这对于 使用指标 实时分析许多符号的专家顾问来说是不可接受的。在大多数情况下（99%），我在Expert Advisors中需要一个严格指定的最新条数和所有条数。其他的东西对我来说都太多了。当然，不仅仅是对我来说...
它被忽略了。因此，我把这种计算转移到我的专家顾问的代码中。
啊，是的！还有许多自写的补丁的出现。一些聪明的文章甚至被写出来并发表，比如下面这篇文章。
减少辅助指标的内存消耗
通过Zigzag和ATR的例子来实现指标类的实施
...
如果你把常规显示的指标和短线计算的指标分开，就很容易在长线累积指标上出现背离。
同时这也会导致我们这边出现危险的拐杖。
一个好的方法是每张图表设置100000条，或者切换到x64。
Renat:
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
一般来说，没有什么变化。在MQL5中限制指标缓冲区大小的可能性的请求被拒绝，如果您的程序由于使用了许多指标缓冲区而开始消耗大量的内存--那么它就被称为 "编程错误"。
"在专家顾问中，我最经常（99%）需要一个严格的特定数量的最后一条和所有。所有不必要的事情对我来说都太多了。当然，不仅仅是我......"(с)
2）指标不能被计入短历史，因为它们是所有进程（终端、窗口、专家）之间共享的资源。而在指标上有许多更新、同步和重新计算市场环境的规则。
3. 如果你把常规显示的指标和短线计算的指标分开，就很容易在长线累积指标上出现背离。
同时这也会导致我们这边出现危险的拐杖。
1.一个好的方法是每张图表设置100000条，或者切换到x64。
1.这就是我所做的。尽管如此，这仍然是一个令人不舒服的妥协。理想情况下，如果我完全不考虑开发问题（纯粹作为一个用户），我希望在设置计算长度时能有一个选择。对于图表--全长（虽然不一定，但也有严重的大的例外），对于专家--完全是必要的长度。
2.作为一个开发者，我理解 这种方法的困难和同时的局限性，然而内存消耗也是我的问题，它顽固地不想落入后台。我有一个具体的建议--解决方案--将计算周期（让我们这样称呼它）视为一个平等的参数--不比其他参数差。那么具有所有类似参数的两个指标，但计算周期不同，只是两个不同的指标。是的，理论上有一些愚蠢的用例会导致额外的费用（如果用户会乘以计算周期），但在实践中不太可能。 如果有人想顺水推舟，他/她是有罪的。 就像现在所有的用户都有罪，"开了太多的指标，没有注意减少TERMINAL_MAXBARS"。
我知道 在EMA计算中，从时间开始的所有条形都被使用，但我也知道在随机指标、RSI和大量的（主要的）其他指标中，计算是在有机 长度上进行的。而这些知识 使我可以灵活地选择计算周期（MaxBar）。 只要给我一个选择。
就像现在所有用户 "开了太多的指标而不注意减少TERMINAL_MAXBARS "一样，是他们的错。
是的，特别是在冠军赛条件下，你根本无法影响TERMINAL_MAXBARS的大小。
1.我已经这么做了。不过，这仍然是一个令人不舒服的妥协。理想情况下，如果我们完全不考虑开发问题（纯粹作为一个用户），我希望在设置计算长度时有一个选择。对于图表--全长（虽然不一定，但也有严重的大的例外），对于专家--完全是必要的长度。
2.作为一个开发者，我理解 这种方法的困难和同时的局限性，然而内存消耗也是我的问题，它顽固地不想落入后台。我有一个具体的建议--解决方案--将计算周期（让我们这样称呼它）视为一个平等的参数--不比其他参数差。那么具有所有类似参数的两个指标，但计算周期不同，只是两个不同的指标。是的，从理论上讲，有一些愚蠢的变体会导致额外的费用（如果用户乘以计算周期），但在实践中不太可能。 如果有人想超过这个坎 - 那是他自己的错。 就像现在所有的用户都犯了 "开了太多的指标而没有注意到减少TERMINAL_MAXBARS"。
我知道 在EMA的计算中，从时间开始的所有条形都被使用，但我也知道在随机指标、RSI和大量的（主要的）其他指标是按有机 长度计算的。而这些知识 使我可以灵活地选择计算周期（MaxBar）。 只要给我一个选择。
这个信息很清楚。
我们自己也想减少资源的消耗。也许解决方案可以是一些函数IndicatorMaxDepth(uint len)，它将只作用 于该EA中创建的指标。
但问题是，在测试过程中，累积模式下指标的缓冲区会与历史一起增长，而且不会有保存。实时修剪指标的历史，同时保持指定的深度，充满了美丽的故障和打击程序员的头脑，他们计数/习惯于图表和指标缓冲区的条形同步。
一个更好的选择是转移到x64。
我们将修改指标的缓存，现在使用的是最大效率原则与节省内存原则。我们将尝试立即卸载被拒绝的指标，而不是像现在这样在内存中保留一段时间。这将使我们有可能通过IndicatorRelease直接卸载，连续调用数百个指标。
当然，如果有人会在市场扫描模式下调用数以百计的指标而不卸载它们，那么他们必须直接使用64位版本+安装额外内存。
现在，坐在X32上做大规模的测试，这很奇怪。任何像样的x64电脑，16GB内存（不对显卡和显示器狂热），15000卢布就可以买到。