MT5和速度在行动 - 页 78

新评论
 
Valeriy Yastremskiy:

正确理解终端内存与mcl、tix等终端程序内存的堆叠。

不，仅仅是CopyTicks存储了10秒的所需刻度的缓存。例如，要求3Gb的内存，终端将把这3Gb多存储在缓存中。总终端将消耗6GB。如果你做ArrayFree 并为另一个符号请求3Gb，终端将消耗9Gb。以此类推。

 
Valeriy Yastremskiy:

正确理解终端的内存是加在终端程序mcl、tix等的内存中的。

当然了。
 
需要制作一个脚本，根据几个符号的tick历史 按公式创建一个自定义符号 
MqlTick Formula( const MqlTick &Symbol1_Tick
                 const MqlTick &Symbol2_Tick,
                 const MqlTick &Symbol3_Tick,
                 const MqlTick &Symbol4_Tick,
                 const MqlTick &Symbol5_Tick );

看来，100MB的内存应该足以完成这项任务，即使是10亿次。但在MT5中，你不能通过CopyTicks来解决这个任务。

这里是拐杖。

  1. 对每个符号单独调用CopyTicks（每次调用后必须等待缓存释放），通过FileSave将tick历史写入其相应的文件。
  2. 然后，从这些文件中读取蜱虫，并为它们调用公式。

是的，这是一个令人毛骨悚然的拐杖，但没有其他选择。所以，你不能直接用CopyTicks工作。有必要使用蜱虫的文件档案。


最大的内存消耗是在p.1中，即使在每次调用后期望释放缓存的条件下也是如此。在这种情况下，p.2.将免费运行!

 

我同时在8个货币对上进行交易，每个货币对上都有几个专家顾问。虽然在资源方面看起来不错，内存使用率不超过25%，CPU负载不超过10%，但滞后是明显的，比如新图表打开几秒钟，以及在一般交易中。也许有一些最佳做法，至少是抽象的，如何将其全部打包并使其更快地工作？我知道你正在将几个专家顾问系统虚拟成一个。有哪些隐患？发送交易指令 是如何实现的？我应该注意什么？

P.S. 我自己通过Virtual使用同步，通过MT4Orders进行交易，每个图表有一个EA。

 
fxsaber:

同样地。以你的VPS为例。市场筛查人员无法对其进行工作。

ZS 摆脱几个月来一直发生的打嗝现象会很好。在一台有无限内存的机器上运行这个脚本。例如，我不能从6月1日开始上传蜱虫，只是一次一个字符。它只是挂起了CopyTicks，资源消耗为零。

当终端 "挂起 "时，对它进行转储。让我们看看原因是什么。

 
traveller00:

我同时在8个货币对上进行交易，每个货币对上都有几个专家顾问。虽然在资源方面看起来不错，内存使用率不超过25%，CPU负载不超过10%，但滞后是明显的，比如新图表打开几秒钟，以及在一般交易中。也许有一些最佳做法，至少是抽象的，如何将其全部打包并使其更快地工作？

使用新的MT4Orders（该分支创建后历史处理加速），快照当前环境：订单和头寸。我的一切都在飞。

我知道你正在将几个专家顾问系统虚拟成一个。有哪些隐患？发送交易指令 是如何实现的？我应该注意什么？

我正在使用同步OrderSend，但我禁用了MT5检查。

关于交易、自动交易系统和策略测试的论坛

图书馆: MT4Orders

fxsaber, 2020.09.29 08:45

有了这句话。

MT4ORDERS::OrderSend_MaxPause = 0; // Отключение проверки корректности работы MT5-OrderSend.

可以用来禁用这一切。在MT5交易历史迟缓 的情况下可能很有用，因为MT4Orders有时会通过参考该历史来检查MT5-OrderSend的正确性（甚至纠正）。

我不建议这样做。


每一组（一组输入参数）都有自己的虚拟。同步器浏览所有的美德，并为每个美德进行同步。它需要在一个循环中做到这一点，而不是从第一个虚拟开始。

在任何OrderSend调用后（在同步器内），必然会有一个快照，并且在OrderSend执行时间内的新刻度被添加到（所有的Virtuals）。也就是说，在任何假设的停顿之后，我们都会使一切变得新鲜。

每次只通过CopyTicks采取新鲜的蜱虫。没有SymbolInfoTick可供滚动使用。确保如果CopyTicks_LastTick.time_msc < SymbolInfoTick.time_msc（它经常发生，即使调用是一个接一个（以任何顺序），那么同步器没有被启用。否则，你可能会遇到实际时间限制被执行，但虚拟时间限制没有被执行。而且在同步方面也会有问题。

我通过VIRTUAL::Snapshot制作快照。除了明显的速度之外，它还允许你将你的符号与其他的符号分开--只有你的符号才能到达那里。这使得速度更快。另外，在快照中不仅是历史被禁用。

#define  VIRTUAL_SNAPSHOT_WITHOUT_HISTORY // Отказ от снепшота истории для повышения производительности

但也有需要访问历史的字段（下面有标记）。

#define  MACROS(A) this.##A = ::Order##A();

  bool ORDERS::Copy( const bool WithoutHistory = false )
  {
    MACROS(CloseTimeMsc)

    if (WithoutHistory && !this.CloseTimeMsc) // Для исторических ордеров оставляем все без изменений.
    {
      const string Str = NULL;
      this.comment = Str;

      this.Commission = 0;
      this.OpenPriceRequest = this.OpenPrice;
    }
    else // В MT4Orders требуется обращение к истории.
    {
      const string Str = ::OrderComment();
      this.comment = Str;

      MACROS(Commission)
      MACROS(OpenPriceRequest)
    }

之前我还检查了LastDeal.time_msc是否比LastTick.time_msc大。如果这个条件没有得到满足，我就拒绝同步，原因很明显。但这样的检查会消耗大量的资源（它与历史记录一起工作），所以我拒绝了。


交易的功能 - OnTick。


我大概列举了主要的几项。

 

同步，我认为不仅是OrderSend，还有所有的交易订单，包括修改、删除等？


SymbolInfoTick没有被抛出，因为ticks的顺序可能会被打乱？而CopyTicks的顺序是完全正确的。


事实证明，SymbolInfoTick只需要用来检查时间，而这就是全部？所有的交易等都只由CopyTicks 纠正？


试图在1对1的图表中打包几个EA有什么意义吗？没有什么不可能，但想了解是否值得麻烦和重写，或者利润会很低？

 
traveller00:

试图将几个EA装入1对1的图表中是否有意义？没有什么不可能，但想知道是否值得麻烦和重写，或者利润会不会很小？

利润从哪里来？每个人都会在交易 时等待他们中的任何一个。

而且只是少了一些平行的东西。

除非你能为所有人保留一个订单缓存，但好处是值得怀疑的......

 
Anton:

当终端 "挂断 "时，对它进行转储。看看是什么原因造成的。

重现该问题的代码对你来说还不够吗？还是不再生了？

 
traveller00:

同步，我认为不仅是OrderSend，还有所有的交易订单，包括修改、删除等？

我是指MT5-OrderSend。

不传递SymbolInfoTick，因为ticks的顺序可能会被破坏？而CopyTicks完全按照正确的顺序进行。

因为会有漏洞。

所以，SymbolInfoTick只需要用来检查时间，就这样？

是的。

所有的交易等将只由CopyTicks进行？

只有。

试图将几个EA装入1对1的图表中是否有意义？没有什么不可能的事，但想知道是否值得麻烦和重写，或者利润将是最小的？

这对我来说是一个巨大的帮助。


每个单次通过（在单次测试模式下）最后都将其实例写到同一个文件中。因此，在优化后查看一些通道后，我得到一个包含这些通道数据的文件。然后我在这个文件中过滤它们，只留下看起来不错的东西。在启动机器人时，我只需使用FileSelectDialog来选择这个文件。因此，它交易的是投资组合。


事实证明，优化需要20分钟。通行证预览 - 3分钟。他们的过滤器 - 3分钟。启动机器人投入运行 - 秒。该机器人不需要被编译。追踪版本和图表 - 类似地。

在启动时，我可以看到每组的报告。在任何时候，我都可以从现实中看到虚拟和它的名字的状态，以及虚拟和现实中的热键详细的HTML-Report。既有单套的，也有整个组合的。


由于 "美德 "的交易统计是专门快速编写的，因此可以快速地相互比较各套交易（从键盘上）。

附加的文件：
clip0184.gif  64 kb
1...717273747576777879808182838485...94
新评论