MT5和速度在行动 - 页 17

新评论
 

请注意，HistorySelect 会将所选历史的物理快照放到EA的本地缓存中，这样你就可以毫无顾虑地去查看它们。如果不这样做，你会得到非常不愉快的效果，因为账户历史是异步更新/同步的。更不用说用户自己可以从界面上手动改变历史的深度。

因此，这种复制成本。如果你故意从多个线程中同时强制复制这段历史到缓存中，那就更是如此。

我们已经在采样操作上做了很多优化，现在我们考虑的是最佳的缓存更新，而实际上99%的采样将是完全无用的，将被跳过的。

也就是说，除非你特别随机化采样限制，否则缓存将显示接近100%的点击率。

很可能下周就已经有了有效的解决方案。

 
Renat Fatkhullin:

请注意，HistorySelect会将所选历史的物理快照放到EA的本地缓存中，这样你就可以毫无顾虑地去查看它们。如果不这样做，你会得到非常不愉快的效果，因为账户历史是异步更新/同步的。这还不算，用户可以自己从界面上手动改变历史的深度。

有一个订单表和一个交易表。既然在调用HistorySelect的时候知道四个索引就足够了，我们为什么还要做物理抓取呢？

这就是为什么复印费用如此之高。特别是当我们具体处理从多个线程同时强制复制这段历史到缓存的时候。

我们已经在采样操作上做了很多优化，现在我们考虑的是缓存的最佳更新，而实际上99%的采样将是完全无用的，将被跳过。

也就是说，除非你特别随机化采样限制，否则缓存将显示接近100%的点击率。

很可能下周就已经有了有效的解决方案。

HistoryDealSelect和HistoryOrderSelect现在可以销毁相关样本。为什么没有像MT4那样，通过索引来访问这两个表？引入新的功能。

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

虫子、虫子、问题

fxsaber, 2020.08.20 11:28

新的内部职能。 
int OrderExist( const string symbol, ENUM_ORDER_TYPE type, ulong magic, ulong &tickets[] );

int PositionExist( const string symbol, ENUM_POSITION_TYPE type, ulong magic, ulong &tickets[] );

指数正在要求它。我不明白为什么我应该知道我账户中的交易数量。

 

而这些表格可以在任何时候改变。其中的个别记录也可以。

由于异步操作、同步过程和用户手动设置的深度模式，没有人能够保证其不变性。

正如我在上面写的，我们将应用智能缓存技术，这将把选择函数的成本降低到零。当然，除非你特别将抽样限制随机化。最后日期可以改变，如果总是在未来/最后时间，就不会使缓存失效。最近的交易将被稀少地添加到缓存中。


在MT4中，它的工作方式是一样的，只是缓存创建被隐藏了。在MT4的每个OnTick/OnStart，终端会自动为每个EA创建一个市场环境的快照。

因此，你无法从MQL4代码中评估数据准备的真正延迟。幸运的是，在MT4中，数据是小而简单的。


在MT5中，我们放弃了自动创建市场环境的费用，以减少延迟，不做不必要的工作。相反，我们已经将完全的成本控制权交给了机器人开发者，他们可以准确地要求他们所需要的东西。

请注意，与MT4相比，MT5的市场环境规模是巨大的--它根本无法复制。

通过你的测试，你已经利用了这些昂贵的样本之一。

我们将解决这个问题--这符合我们的利益。

 
Renat Fatkhullin:

而这些表格可以在任何时候改变。其中的个别记录也可以。

由于异步操作、同步过程和用户手动设置的深度模式，没有人能够保证其不变性。

你是说在已经是最后一笔交易之前，另一笔交易可能会出现在交易历史中？如果一个交易发生了变化，另一个。但要楔入一个已经存在的名单内--我还没有注意到这一点。

 

OrderExist和PositionExist是特殊的优化函数，可以避免愚蠢地在所有订单或头寸中循环，按符号、交易类型和medzhik搜索条目。

其结果是一系列的门票。


使用这些功能的程序可能会节省很多钱。特别是在大量调用未结头寸和订单时，不断地、反复地进行超限循环。

我们将在未来实施更有效的功能来获取大量的 贸易数据。

该语言也将得到极大的加强和简化，具有更强大的功能。

 
fxsaber:

你是说，在已经完成的最后一笔交易之前，交易历史中可能还有另一笔交易？如果交易发生了变化，那就再来一次。但要楔入一个已经存在的名单内--我还没有注意到这一点。

理论上，是的。

不要忘记同步过程。平台中大量的进程是异步的。

例如，与交易所或流动性供应商整合的网关可能会发送交易报告，延迟时间为几秒钟甚至是几分钟。通常情况下，api根本不提供对历史记录的访问，而是提供缓慢和无节奏的报告生成器。

在开市时，或由于意外的网关重新连接，报告可能会被延迟。它们被复制到服务器上的历史记录，并立即异步发送到终端。由于按日期排序，它们被插入正确的位置，同时，你可以开立新的交易。

大多数集成API是如此不识时务，功能紊乱，几乎让人无法做出有保障的 网关。尽管有一种观点认为这是他们的开发者故意破坏的产物。

 
Renat Fatkhullin:

OrderExist和PositionExist是特殊的优化函数，可以避免愚蠢地在所有订单或头寸中循环，按符号、交易类型和medzhik搜索条目。

其结果是一系列的门票。


使用这些功能的程序可能会节省很多钱。特别是在大量调用未结头寸和订单时，不断地、反复地进行超限循环。

我们将在未来实施更有效的功能来获取大量的 贸易数据。

该语言也将得到极大的加强和简化，具有更强大的功能。

Renat，一个很大的要求是，在使用Copy...函数时，能够访问TERMINAL_MAXBARS之外的报价。至少只有一分钟的时间范围。你也可以为此单独制作一个函数。
但要想获得这些数据，你必须始终将TERMINAL_MAXBARS设置为无限（此外，它还会使终端过载），这非常不方便，因为你不需要对所有符号都进行无限。
据我所知，如果你复制了所有的小MN1周期条，所有的M1条仍然会被下载，但没有权限。
当然，你可以下载所有的ticks，因为它们不受这个限制，但这更耗时，不幸的是ticks并不总是与整个分钟历史相吻合。

 
Nikolai Semko:

Renat，一个很大的要求是，在使用Copy...函数时，可以访问TERMINAL_MAXBARS之外的报价。至少只有一分钟的时间范围。你也可以为此单独制作一个函数。
但要想获得这些数据，你必须始终将TERMINAL_MAXBARS设置为无限（此外，它还会使终端过载），这非常不方便，因为你不需要对所有符号都进行无限。
毕竟，据我所知，如果你复制所有的小MN1周期条，无论如何，所有的M1条都会被下载，但没有权限。
当然，你可以下载所有的ticks，因为它们不受这个限制，但这更耗时，不幸的是ticks并不总是与整个分钟历史相吻合。

不，超出这些限制的历史不会被拾起并检查是否同步。此外，没有地方可以储存它们（我们不会建立额外的隐形缓存），我们不会以非经济模式爬盘，也不会建立拐杖。

一般来说，这是一个有害的想法，因为开发人员会立即开始编写绝对低效的算法，并建议交易者 "设置5000条，或更好的1000条"，并指责我们速度慢和效率低。

我们特意允许控制分配给图表的资源数量。现在是64位，内存很便宜--在规则和架构内使用适当的设置。

我们不会改变这种行为。

 
Renat Fatkhullin:

不，超出这些限制的历史不会被提出来，并检查是否同步。此外，没有地方可以存储它们（我们不会建立额外的隐形缓存），我们也不会以不经济的模式爬过磁盘。

事实上，这是一个有害的想法，因为开发人员将立即开始编写绝对低效的算法，并建议交易者 "设置5000条或更好的1000条"，并指责我们速度慢和效率低。

我们特意允许控制分配给图表的资源数量。现在是64位，内存很便宜--在规则和架构内使用适当的设置。

我们不会改变这种行为。

好的。明白了。谢谢。划掉了。
，当然，我也想争论一下不经济。 我将不得不留下无限的，结果是所有开放的（例如我目前有14个图表）将保留所有的历史，尽管我对大多数的图表只需要5000个。相反，这将是更不经济的。
另外，我不需要这些数据被存储。我将负责存储。我已经启动了所有分钟条形图的加载，把它们弄到一个数组中，我不再需要它了，如果它们的大小超过TERMINAL_MAXBARS，所有缓存都可以被删除。所以，也许这就是一个不存储缓存的独立函数的作用。

当然，我同意顽皮的人可以用这种周期性的负载中止系统。

 

你只有5000和unlim两种状态？

你是你自己幸福的主谋。

1...101112131415161718192021222324...94
新评论