错误、漏洞、问题 - 页 1938 1...193119321933193419351936193719381939194019411942194319441945...3184 新评论 [删除] 2017.07.21 14:33 #19371 Aleksey Vyazmikin:尝试了你的方案--在误差范围内的变化它是。 2017.07.21 17:23:20.046 核心1 Si-9.17,M1: 107509点,35385条产生。环境在0:00:00.032同步。测试在0:02:52.037通过(包括ticks预处理0:00:00.031)。 2017.07.21 17:23:20.046 核心1 Si-9.17,M1:从登录到停止测试总时间为0:02:52.069(包括历史数据同步的0:00:00.032)。 2017.07.21 17:23:20.046 核心1 使用了351Mb的内存,包括32Mb的历史数据,64Mb的tick数据用你的代码成为 2017.07.21 17:27:37.393 核心1 Si-9.17,M1: 107509点,35385条产生。环境在0:00:00.031进行同步。测试在0:02:58.013通过(包括ticks预处理0:00:00.031)。 2017.07.21 17:27:37.393 核心1 Si-9.17,M1: 从登录到停止测试总时间0:02:58.044(包括历史数据同步的0:00:00.031)。 2017.07.21 17:27:37.393 核心 1 使用了352Mb内存,包括32Mb的历史数据,64Mb的tick数据MT4 2017.07.21 17:27:57.070 RUBRUR,M1: 在0:00:04.306(总时间0:00:11.357)中处理了225314个tick事件(35701条,231783条状态)。 在这里,你也可以尝试删除函数中的数组声明,使其成为全局性的。也就是说,让数组arr[ 1 ]成为全局性的,并从所有的函数中删除字符串double arr[ 1 ]; 。 Aleksey Vyazmikin 2017.07.21 15:19 #19372 Andrey Khatimlianskii:已经向你建议了一个现成的解决方案 -https://www.mql5.com/ru/code/18305根据你的要求来判断。这是最适合你的。 我试了一下,结果是这样的。 2017.07.21 18:15:16.395 Core 1 Si-9.17,M1: 107509 ticks, 35385 bars generated.环境在0:00:00.047同步。测试在0:02:37.748通过(包括ticks预处理0:00:00.031)。 2017.07.21 18:15:16.395 核心1 Si-9.17,M1: 从登录到停止测试的总时间为0:02:37.795(包括历史数据同步的0:00:00.047)。 2017.07.21 18:15:16.395 核心 1540Mb 内存的使用,包括32Mb的历史数据,64Mb的tick数据 用处不大,而且由于不清楚的原因,财务结果是不同的:( Aleksey Vyazmikin 2017.07.21 15:30 #19373 Alexey Kozitsyn: 你也可以尝试删除函数中的数组声明,使其成为全局性的。也就是说,让数组arr[ 1 ]成为全局性的,并从所有的函数中删除字符串double arr[ 1 ];。下面是结果2017.07.21 18:28:58.653 核心1 Si-9.17,M1: 107509点,35385条产生。环境在0:00:00.078同步。测试在0:02:51.477通过(包括ticks预处理0:00:00.031)。 2017.07.21 18:28:58.653 核心1 Si-9.17,M1:从登录到停止测试总时间为0:02:51.555(包括历史数据同步的0:00:00.078)。 2017.07.21 18:28:58.653 核心1 使用了359Mb的内存,包括32Mb的历史数据,64Mb的tick数据 是的,它比以前快了一点,但它不能与MQL4相比...... Aleksey Vyazmikin 2017.07.21 17:49 #19374 如果我假设这不是代码呢?现在,我的EA已经慢得很厉害,大约10分钟内无法终止--我根本没有对它做任何改动....。 Aleksey Vyazmikin 2017.07.21 18:04 #19375 Aleksey Vyazmikin: 如果我假设这不是代码呢?目前,我的专家顾问一直在放慢速度,大约10分钟内都无法完成工作--我没有对它进行任何修改....。 事实证明,滴答声的模式已经改变......神秘的。 Aleksey Vyazmikin 2017.07.21 18:27 #19376 所以,先生们,现在我很 困惑--剪掉了整个无效的OnTick(),得到了一个惊人的结果2017.07.21 21:22:08.048 核心 1 Si-9.17,M1: 107509 ticks, 35385 bars generated.测试在0:02:32.928 通过(包括ticks预处理0:00:00.031)。 2017.07.21 21:22:08.048 核心 1 346Mb内存的使用,包括32Mb的历史数据,64Mb的tick数据 然后产生了一个想法,也许宣布和接收的外部指标的速度在减慢,如果它们甚至没有被查询到,如果是这样,那么为什么剖析对它保持沉默,并花了我一天的时间...... Andrey Khatimlianskii 2017.07.21 21:28 #19377 Aleksey Vyazmikin:...如果是这样的话,那么为什么剖析对它保持沉默,并从我的生活中抽取一天...因为你没有发布你的代码,你在这里占用了大家一天的生活。来自宇宙的反转 ) Vitaly Muzichenko 2017.07.21 21:32 #19378 Andrey Khatimlianskii:因为你没有放出你的代码,从这里的每个人身上夺走一天的生命。来自宇宙的反转 )这就是 你所说的吗? Andrey Khatimlianskii 2017.07.21 21:40 #19379 Vitaly Muzichenko:这就是 你所说的吗?看起来像 Aleksey Vyazmikin 2017.07.21 21:47 #19380 Vitaly Muzichenko:这就是 你所说的吗?不,不,我张贴了剖析的结果! 1...193119321933193419351936193719381939194019411942194319441945...3184 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
尝试了你的方案--在误差范围内的变化
它是。
2017.07.21 17:23:20.046 核心1 Si-9.17,M1: 107509点,35385条产生。环境在0:00:00.032同步。测试在0:02:52.037通过(包括ticks预处理0:00:00.031)。
2017.07.21 17:23:20.046 核心1 Si-9.17,M1:从登录到停止测试总时间为0:02:52.069(包括历史数据同步的0:00:00.032)。
2017.07.21 17:23:20.046 核心1 使用了351Mb的内存,包括32Mb的历史数据,64Mb的tick数据
用你的代码成为
2017.07.21 17:27:37.393 核心1 Si-9.17,M1: 107509点,35385条产生。环境在0:00:00.031进行同步。测试在0:02:58.013通过(包括ticks预处理0:00:00.031)。
2017.07.21 17:27:37.393 核心1 Si-9.17,M1: 从登录到停止测试总时间0:02:58.044(包括历史数据同步的0:00:00.031)。
2017.07.21 17:27:37.393 核心 1 使用了352Mb内存,包括32Mb的历史数据,64Mb的tick数据
MT4
2017.07.21 17:27:57.070 RUBRUR,M1: 在0:00:04.306(总时间0:00:11.357)中处理了225314个tick事件(35701条,231783条状态)。
已经向你建议了一个现成的解决方案 -https://www.mql5.com/ru/code/18305
根据你的要求来判断。
这是最适合你的。
我试了一下,结果是这样的。
2017.07.21 18:15:16.395 Core 1 Si-9.17,M1: 107509 ticks, 35385 bars generated.环境在0:00:00.047同步。测试在0:02:37.748通过(包括ticks预处理0:00:00.031)。
2017.07.21 18:15:16.395 核心1 Si-9.17,M1: 从登录到停止测试的总时间为0:02:37.795(包括历史数据同步的0:00:00.047)。
2017.07.21 18:15:16.395 核心 1540Mb 内存的使用,包括32Mb的历史数据,64Mb的tick数据
用处不大,而且由于不清楚的原因,财务结果是不同的:(
你也可以尝试删除函数中的数组声明,使其成为全局性的。也就是说,让数组arr[ 1 ]成为全局性的,并从所有的函数中删除字符串double arr[ 1 ];。
下面是结果
2017.07.21 18:28:58.653 核心1 Si-9.17,M1: 107509点,35385条产生。环境在0:00:00.078同步。测试在0:02:51.477通过(包括ticks预处理0:00:00.031)。
2017.07.21 18:28:58.653 核心1 Si-9.17,M1:从登录到停止测试总时间为0:02:51.555(包括历史数据同步的0:00:00.078)。
2017.07.21 18:28:58.653 核心1 使用了359Mb的内存,包括32Mb的历史数据,64Mb的tick数据
是的,它比以前快了一点,但它不能与MQL4相比......
如果我假设这不是代码呢?目前,我的专家顾问一直在放慢速度,大约10分钟内都无法完成工作--我没有对它进行任何修改....。
所以,先生们,现在我很 困惑--剪掉了整个无效的OnTick(),得到了一个惊人的结果
2017.07.21 21:22:08.048 核心 1 Si-9.17,M1: 107509 ticks, 35385 bars generated.测试在0:02:32.928 通过(包括ticks预处理0:00:00.031)。
2017.07.21 21:22:08.048 核心 1 346Mb内存的使用,包括32Mb的历史数据,64Mb的tick数据
然后产生了一个想法,也许宣布和接收的外部指标的速度在减慢,如果它们甚至没有被查询到,如果是这样,那么为什么剖析对它保持沉默,并花了我一天的时间......
...如果是这样的话,那么为什么剖析对它保持沉默,并从我的生活中抽取一天...
因为你没有发布你的代码,你在这里占用了大家一天的生活。来自宇宙的反转 )
因为你没有放出你的代码,从这里的每个人身上夺走一天的生命。来自宇宙的反转 )
这就是 你所说的吗?
这就是 你所说的吗?
看起来像
这就是 你所说的吗?
不,不,我张贴了剖析的结果!