程序库: TesterBenchmark - 页 3

新评论
 
Andrey Khatimlianskii:

瓦西里，你是在认真讨论 OrderSend 在测试版和实际版中执行速度的可比性吗？

在线执行速度是最慢的，因为它会向服务器发送信息并等待回应，而在测试器中（如果不包括延迟，但这是不可能的），发送和等待都是即时发生的。

这个库的任务只是测量测试仪的速度（在交易功能方面）。

是的，我没有考虑到这一点。我错了。具体来说，OrderSend 在测试器中的运行速度要快得多。但我还是要说，系统功能占用了大部分测试时间。在 MT5 中，这部分时间被占用得很好，因为与 MT4 不同，在 MT5 中可以完全模拟交易环境。这就是为什么即使流水线加速了 16%，也只是流水线总耗时 5%中的 16%。也就是说，在 MT5 中进行代码优化的 任何想法都是高尚的，但毫无意义，因为我们最多只能将指数提高 5%。

 
Vasiliy Sokolov:

是啊，我没想那么多。我错了。OrderSend 在测试器中运行得更 快。但我还是要说，系统功能占用了大部分测试时间。在 MT5 中，这部分时间被占用得很好，因为与 MT4 不同，在 MT5 中可以完全模拟交易环境。这就是为什么即使流水线加速了 16%，也只是流水线总耗时 5%中的 16%。也就是说，在 MT5 中进行代码优化 的任何想法都是高尚的，但毫无意义，因为我们最多只能将指数提高 5%。

我不同意最后一种说法。

得益于 fxsaber 的研究，MT5 已 将历史交易工作的速度提高了 几个数量级。

 
Andrey Khatimlianskii:

我不同意最后一种说法。

多亏了 fxsaber 的研究，MT5 在处理历史交易方面 已经 快 了很多。

我不是在争辩。Fxsaber 为语言的发展和整个社区做出了巨大贡献。他做了正确的事情。MT5 中存在很多错误，有人发现这些错误非常好。但我们不应将 MT5 工作中的重大错误（导致工作速度以数量级下降）与在 SB 代码中抓跳蚤混为一谈。在某些地方，加快程序库的速度当然是可能的，甚至是必要的。但如果其中没有重大错误，就不会出现数量级的加速。

 
Vasiliy Sokolov:

我不是在争论。Fxsaber 为语言和整个社区做出了巨大贡献。他做了正确的事情。MT5 中存在很多错误，有人发现这些错误是件好事。但我们不应将 MT5 工作中的重大错误（导致工作速度以数量级下降）与在 SB 代码中抓跳蚤混为一谈。在某些地方，加快程序库的速度当然是可能的，甚至是必要的。但如果其中没有严重错误，就不会有数量级的加速。

我甚至都没想过 SB。

我认为它只是用来比较的。

 
Andrey Khatimlianskii:

我不同意最后一种说法。

多亏了 fxsaber 的研究，MT5 已 将历史交易工作的速度提高了 几个数量级。

顺便提一下，历史交易 早在 2013 年就出现了问题。我记得当时我注意到以下代码并非线性工作：

int total = HistoryDealsTotal();
for(int i = 0; i < total; i++)
{
   ulong ticket = HistoryDealTicket(i);
   HistoryDealSelect(ticket);
}

也就是说，i 越多，HistoryDealSelect 的运行速度就越慢。速度呈指数下降。因此，我不得不在 Excel 中绘制了这种速度减慢的曲线图，并与服务台进行了沟通。所以，是的，过去有，将来也会有。

 

现在我对代码进行了一些调整，将 OrderSend 更改为OrderSendAsynch。结果出乎意料地不同：

85% 的时间被 HistorySelect 占用。也就是说，我们又回到了系统调用，但有点不同。

 
该库就是为此目的而编写的
在编写不同版本的代码时，可能有必要在测试仪中测量它们对智能交易系统整体性能的影响。这不仅能让您了解所编写的代码与其他代码相比有多优化，还能为将来快速优化智能交易系统提供先决条件。通过这种方法，我们可以找出 EA 性能的 "瓶颈"。

这种方法不仅适用于 MT4Orders.mqh，也适用于 Trade.mqh--SD 后 速度明显加快。 此外，使用该库的结果还让我们明显加快了其他一些功能（尤其是）。

合理的解决方案 等。

事实上，优化时间在很大程度上取决于代码的编写方式。该库不仅想方便地引起我自己的注意，也想引起其他人的注意。

举个例子（请作者见谅），kodobase 中有许多 EA，就性能而言，在 Optimiser 中并不出众，至少是因为使用了交易库。事实上，这甚至是 kodobase（我相信也包括 Market）的一个祸害，一个聪明而强大的 OOP 顾问会抵消 MT5 测试器的所有速度能力。

几乎没有任何东西是为测试器编写的。而这正是使用 TS 的一个重要组成部分。

 
fxsaber:

...当一个精明强干的 OOP 顾问使 MT5 测试仪的所有速度功能失效时。

再看看您例子中的剖析。一切都受阻于极其缓慢的 HistorySelect(0, TimeCurrent)。在 OOP 中，您可以绕过 HistorySelect 的调用，与调用纯 MQL5 函数相比，这大大减少了程序的执行 时间。认为 OOP 使 MT5 的所有速度功能失效的说法是不正确的。在某些情况下，由于使用了 OOP，您可以提高速度，例如 HistorySelect。

 
Vasiliy Sokolov:

再看看你的示例的剖析。一切都受阻于极其缓慢的 HistorySelect(0,TimeCurrent)。在 OOP 中，可以绕过 HistorySelect 的调用，与调用纯 MQL5 函数相比，这大大减少了程序的执行 时间。认为 OOP 使 MT5 的所有速度功能失效的说法是不正确的。在某些情况下，由于 OOP 的存在，您反而可以加快速度，例如 HistorySelect。

由于某些原因，您没有注意到只有在没有未结头寸时才会调用 HistorySelect。而且，新头寸会在此之后立即打开。也就是说，历史记录很少被调用。事实上（至少查看日志中的时间），测试器中的时间因实现方式而异。


我通过 OOP 编写一切，甚至从未暗示过它可能会很慢。绝大多数热衷于 OOP 的作者有时会创造出非常方便和漂亮的设计。然而，他们并不关注其解决方案的性能。这一点对于测试人员来说非常重要。每个人都希望优化自己的 EA，使其运行时间更快（或在云计算中更便宜）。经常发生的情况是，一些写了很久的可自动插入的 OOP 模块包含一个瓶颈。当然，没有人会注意到这一点。


您可以编写自己的智能交易系统，显示所使用的交易 API 的性能。例如，删除原始模块中的历史访问和手数计算。

 
fxsaber:

您可以编写自己的智能交易系统，显示所使用的交易 API 的性能。例如，从原来的程序中删除历史访问和手数计算。

在 CStrategy 中，交易操作 直接通过 CTrade 执行。也就是说，CStrategy 完全没有自己的交易逻辑。在测试的智能交易系统中，除了在 N 秒后开仓/平仓外，我没有看到任何其他交易逻辑。CStrategy 也不存储历史仓位，因此很遗憾，这个示例无法在 CStrategy 中实现。

fxsaber:

绝大多数热衷于 OOP 的作者有时会创建非常方便和漂亮的结构。

遗憾的是，绝大多数热衷于 OOP 的作者原则上并不存在。包括 MetaQuotes 的 SB 作者在内，整个资源中可能只有 5-10 位 OOP 作者。我们为数不多，但我们是密封的：)

fxsaber:

我通过 OOP 编写所有内容，甚至从未暗示过它可能会很慢。绝大多数特别热衷于 OOP 的作者有时会创建非常方便和漂亮的设计。然而，他们并不关注其解决方案的性能。这一点对于测试人员来说非常重要。每个人都希望优化自己的 EA，使其速度更快（或在云计算中更便宜）。经常发生的情况是，一些写了很久的自动 OOP 模块包含一个瓶颈。当然，没有人会注意到这一点。

OOP 代码执行速度慢于过程代码这一事实并不能说明什么。让我们直奔主题：哪些 CTrade 方法是瓶颈？为什么？对这些方法的剖析能说明什么？如何在测试器中识别速度慢的代码段？

1234
新评论