Конечной целью трейдера является извлечение прибыли посредством торговых операций на финансовых рынках. В этой статье дается описание терминов и процессов торговой платформы MetaTarder 5, знание которых необходимо для правильного понимания работы торговых функций языка MQL5. Ордера — это принятые торговым сервером запросы на совершение торговых...
我觉得如果没有论坛成员的支持，这堵MQ墙将无法通过。代码很短，专业人员应该能很快搞清楚。那里没有任何缺陷。这清楚地表明，通过头寸获得的价格比从市场观察获得的价格要快得多。MQ怎么会看不到这些明显的东西--我不明白。
1.你的测试由于条件所限，真正计算出的迭代比例很小
实质上，你只计算处理器任务过重并推迟执行远架给定任务的异常情况，因为超过99%的迭代是在不到1微秒内完成的。
而且，即使你设置的条件>0，仍然没有客观性。
2.这种快速操作的时间测量只应作为一个完整的周期时间，而不是一个单一的迭代。
3.但由于你的例子中的周期被限制在10秒内（为什么？对于ticks，我认为0.1秒已经很足够了。因为很可能发生在一秒钟内有3个ticks到达，而这三个ticks将分别执行10秒，并且是并行的），所以不需要计时。计算在给定时间内将执行多少次迭代比较容易。越多，生产力就越高。
我修改了你的代码 "一点"。我认为我的变体更能反映现实。
计算是一个一个地进行的，以便不把两种变体混在一起。偶数的刻度线用于SYMBOL_BID，奇数的--用于GetBid()。
为了以防万一，我添加了和值及其输出，试图欺骗编译器，使之不被优化。
输出的结果是累积的。
我的结果。
正如你所看到的，性能上的差异是有利于标准版的三倍。
正如你所看到的，性能上的差异是有利于原始版本的三倍。fxsaber的原始版本是否显示了GetBid的优势，还是关于更强大/更少负载的PC？
fxsaber的原始版本是否显示出GetBid的优势，还是它的功能更强大/负载更少的PC？
他的变体也显示了GetBid在CPU全负荷下的优势。但与此同时，我的变体在相同的负载下显示出三倍于常规功能的优势。
这 是因为我的变体考虑到了所有迭代获得Bid价格的平均时间，其只有极小部分有异常的挂起。
谁知道出于什么原因，处理器在困难的 "一分钟 "内被常规功能所困（当延迟超过100µ）。但平均时间仍然是普通功能的三倍。
因此，例如，如果(Interval##A>100)这种情况。
而如果(Interval##A > 0)已经很不一样了，显示出常规版本和替代版本之间的非正常延迟的随机分布，以获得投标价格
在同一时间，我的测试在相同的CPU负载下显示。
因此，我认为fxsaber版本的测试远远不够客观。
我没有用代理加载CPU，而是用这个脚本。它的效率更高。
在对fxsaber测试稍作修改后，清楚地表明在计算中迭代的百分比是多少。
即大约0.01%。
你打赌。
如果SymbolInfoDouble(_Symbol,SYMBOL_BID)的平均执行时间约为50纳秒，只考虑执行时间超过100 000纳秒的。
在对fxsaber测试稍作修改后，清楚地表明在计算中迭代的百分比是多少。
即大约0.01%。
你打赌。
如果SymbolInfoDouble(_Symbol,SYMBOL_BID)的平均执行时间约为50纳秒，则只计算那些大于100 000纳秒的遍历。
我们可以简单地使该条件不超过100微秒，但超过3微秒。结果显然是一样的。我们的想法是，分段研究和在不同的执行条件下，在不同的分段和不同的部分可能会有差异。执行的优先次序往往是根据任何事情来决定的。在轻度负载时，一些优先事项，在高负载时，其他优先事项，在关键的时候，那些不会让计算机挂起和崩溃的优先事项，性能进入后台。
一般来说，以超过70%的硬件负荷进行交易是不对的。这几乎是关键的表现。战斗中的EA的铁负荷不应超过60%。
和你已经有了HFT经纪商吗？)
尝试测试SymbolInfoTick，当市场概览中只有一个符号时，以及有几十个符号时，但要求使用一个工具--就像你的例子中那样
很有可能服务器正在发送压缩的流量，并且SymbolInfoTick在数据被解压缩时遇到了周期性的滞后。
即，当有很多符号时，测试时间会有更频繁或更深的下降
在最近的构建中，即使从理论上讲，接收tick流也没有效果。实际上，SymbolInfoTick已经可以使用缓存了，但有些市民一直在寻找一只黑猫。
在测试中，它甚至没有80%。有6个代理在4个核心上运行，即100%保证。
唯一的问题是他的系统的任务调度器是如何处理这种情况的。同时，作者还提出主张，认为是终端的实施造成的。
也就是说，当一台电脑超载时，会人为地制造出一种情况，这时电脑上的一切都会变慢，然后以 "哦，看，为什么终端有时会滞后 "的形式提出一些主张。
让我们闭上眼睛，即使在这样的条件下，它也是 "大约0.01%" - 让细节见鬼去吧!只要说 "没有人关心医院的平均温度"，"交易时滞后会造成问题 "和 "我们想要HFT "就够了。
此外，我们当然希望HFT 在20个专家的旧办公室桌面或一个死的虚拟机上。
PS PositionSelectByTicket()在其实现中当然可以访问一个具有访问同步性的共享资源。而如果你不在每次看涨时选择仓位，你就会读到旧的价格。通过SymbolInfoDouble来 "快照 "更容易。