事件流。 如何控制并使事件闲置?(+已解决) - 页 3 1234567 新评论 TheXpert 2011.11.02 12:03 #21 Yedelkin:同样,如果在mql5-程序的队列中已经有一个 ChartEvent事件 ,或者这种事件正在被处理,那么这种类型的新事件就不会被排队"。嗯,这真的很糟糕。理论上说,这意味着如果一个指标和一个专家顾问独立使用事件,那么在这两种情况下都可能出现跳过。 那么使用该事件作为传输数据的可靠方式就没有意义了。 遗憾的是。 Yedelkin 2011.11.02 12:05 #22 sergeev: 您的问题 "自定义事件 应该以何种频率发送,以便它们不会溢出队列" 我在第一页的答案是 "随着OnChartEvent调用的频率"。 也就是说,一个事件就是一个OnChartEvent。 中间不应该有两个以上的事件。 这就是所有的数学知识。 再一次,阅读第一页。我展示了当终端事件被处理而不是用户事件时,如何避免用户事件的累积。就这么简单。 再一次礼貌地 :)你解决了你的问题,我正试图解决我的问题,是一个不同的计划。在阅读讨论时,我没有找到我问题的答案。你仍然 没有回答我的主要问题(关于内存使用)(如果你选择这样做)。 让我解释一下。我没有 "更新一些函数,但比MQL建议的使用计时器的速度快 "的任务。更是在最后建议的这样一个巧妙的方式。来自几个图表的自定义事件以可变的频率轰击一个包含专家顾问和事件处理函数的独立图表。因此,你狭隘的任务结果(OnChartEvent 内的EventChartCustom)完全不符合我对自定义事件的工作方案。 --- 2011.11.02 12:15 #23 Yedelkin:要澄清的是。我没有 "通过定时器使某些函数的更新速度比MQL建议的快 "的任务。特别是不像最后建议的那样,用如此巧妙的方式。来自几个图表的自定义事件以可变的频率轰击一个包含专家顾问和事件处理函数的独立图表。因此,你狭隘的任务结果(EventChartCustom insideOnChartEvent)完全不符合我对自定义事件的工作方案。这并不复杂,很简单。如果你不能理解,这不是我的问题。 这是一个它不在 OnChartEvent 里面,而是散落在代码中。 你在为它的运作编造你自己的狭隘约束。那是两个。同样,如果在mql5-program的队列中已经有一个ChartEvent 事件,或者这样的事件正在被处理,那么这种类型的新事件将不会被放入队列中。这要么是一个错误,要么是文档错误,要么是条件缺失。事件成功地全部排好队,没有事件被丢弃。否则我的话题就不会出现。我想解决我的另一个问题 事件队列溢出对RAM大小有什么影响? 如果事件队列原来是溢出的,那么溢出队列的事件会去哪里? 雷纳特和罗什已经回答了这个问题吗? Yedelkin 2011.11.02 12:18 #24 Rosh: 如果一个事件被丢弃了,那么它就根本没有被排队。记忆不在增长。 吁!这是我想了解的主要内容。既然TheXpert 说只有几MB花在队列本身,那么很可能内存泄漏在其他地方......在没有证明之前,我们就用这个说法吧。 罗什。 如果出现这种问题,那么事情就非常糟糕了。我认为过度填充的事件队列是寻找内存问题的最后一个地方。 是的,我试图到处寻找。 但要注意的是,在三位被取消资格的专家中,至少有两位是用自定义的事件流工作的(第三位的作者没有回应请求)。Lizar(与自定义事件一起工作)的内存使用率也很高。而tol64的内存消耗极低,因为用户事件的使用频率低于每分钟一次,如果我没有理解错的话。所以,事实证明,你将不得不怀疑随意实现自定义事件概念的效率。 直到你得到一个详尽的答案。 Rashid Umarov 2011.11.02 12:25 #25 Yedelkin:但请注意,在这三个被取消资格的EA中,至少有两个是用自定义事件 流工作的(第三个的作者没有回应请求)。Lizar(与自定义事件一起工作)的内存消耗也很高。而tol64的内存消耗极低,因为用户事件的使用频率低于每分钟一次,如果我没有理解错的话。所以,事实证明,在得到详尽的答案之前,你将不得不怀疑实施自定义事件概念的效率。 而且我们不要忘记,该EA已经从已经在许多工具和时间框架上运行的指标中获得了事件,如果我没有记错的话,总共有大约80个。每个指标都会消耗指标缓冲区的资源,这就是狗被埋葬的地方。 Yedelkin 2011.11.02 12:26 #26 sergeev:这并不复杂,很简单。如果你不能理解,这不是我的问题。按照我的理解,我写道,这很复杂。否则我就不会去碰它。sergeev: 它不在OnChartEvent 里面,而是在整个代码中。 你在编造你自己对它的工作方式的狭隘限制。这是二。是的,是的,EventChartCustom 不是在OnChartEvent 里面,而是,在外面。 现在看一下你自己的代码。void OnChartEvent(int iview, int id, long lparam, double dparam, string sparam) { if (id==CHARTEVENT_CUSTOM+VM_IDLE) { ... } EventChartCustom(m_chart, VM_IDLE, (long)event_idle, 0, ""); // отправили событие с указанием последнего счетчика } 显然,在这段代码中,EventChartCustom不在OnChartEvent 里面,我错得很厉害:)sergeev: 这要么是错误的,要么是一个bug,要么是文件错误,要么是一个被低估的条件。所有成功的事件都留在队列中,没有事件被丢弃。否则我的话题就不会出现。至少还有一个版本:在你的特定情况下,队列根本不会溢出(由于代码效率),所以不存在丢弃事件的事实。 --- 2011.11.02 12:30 #27 Yedelkin:至少还有一个版本:在你的特定情况下,队列根本没有溢出(由于代码效率),所以没有事件被丢弃。这是我开始演示的不抛弃相同事件的特殊案例https://www.mql5.com/ru/forum/5091#comment_112780我在那里写了为什么会发生溢出。是的,是的,EventChartCustom不是在OnChartEvent 里面,而是,在外面。 现在看一下你自己的代码。找到根源!我展示了一个问题及其解决方案的演示。 这个EventChart调用可以在代码的任何地方。 Yedelkin 2011.11.02 12:33 #28 Rosh: 而且我们不要忘了一个事实,专家顾问收到了来自指标的事件,这些指标在许多工具和时间框架上运行,如果我没记错的话,总共有大约80个。每个指标都会消耗指标缓冲区 的资源,这就是狗。 你说的是日本人吗?在我的情况下,这更容易:我有一个通用指标,有8或15个计算指标缓冲区,在一个时间段内运行在6个工具上。也就是说,只有6个指标。而且,从理论上讲,这样的计划在一周内可以消耗2GB? Rashid Umarov 2011.11.02 12:44 #29 Yedelkin: 你说的是日本人吗?好吧,在我的情况下,它更简单:一个通用指标,有8或15个计算指标缓冲区,在一个时间框架上运行6个工具。也就是说,只有6个指标。理论上说,这样的方案在一周内可以消耗2GB? 请阅读《减少辅助指标的内存消耗》一文,它可能是有用的。 Yedelkin 2011.11.02 12:57 #30 Rosh: 请阅读《减少辅助指示器的内存消耗》一文,它可能是有用的。 谢谢,我已经把所有东西都优化到那里了 :)包括在我的记忆中,有这篇文章。我必须等待下一个程度的启蒙 :) 如果专家顾问和指标通过自定义事件一起工作,是否可以分别确定? 1234567 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
Yedelkin:
同样,如果在mql5-程序的队列中已经有一个 ChartEvent事件 ,或者这种事件正在被处理,那么这种类型的新事件就不会被排队"。
嗯,这真的很糟糕。理论上说,这意味着如果一个指标和一个专家顾问独立使用事件,那么在这两种情况下都可能出现跳过。
那么使用该事件作为传输数据的可靠方式就没有意义了。
遗憾的是。
您的问题 "自定义事件 应该以何种频率发送,以便它们不会溢出队列"
我在第一页的答案是 "随着OnChartEvent调用的频率"。
也就是说,一个事件就是一个OnChartEvent。 中间不应该有两个以上的事件。
这就是所有的数学知识。
再一次,阅读第一页。我展示了当终端事件被处理而不是用户事件时,如何避免用户事件的累积。就这么简单。
再一次礼貌地 :)你解决了你的问题,我正试图解决我的问题,是一个不同的计划。在阅读讨论时,我没有找到我问题的答案。你仍然 没有回答我的主要问题(关于内存使用)(如果你选择这样做)。
让我解释一下。我没有 "更新一些函数,但比MQL建议的使用计时器的速度快 "的任务。更是在最后建议的这样一个巧妙的方式。来自几个图表的自定义事件以可变的频率轰击一个包含专家顾问和事件处理函数的独立图表。因此,你狭隘的任务结果(OnChartEvent 内的EventChartCustom)完全不符合我对自定义事件的工作方案。
Yedelkin:
要澄清的是。我没有 "通过定时器使某些函数的更新速度比MQL建议的快 "的任务。特别是不像最后建议的那样,用如此巧妙的方式。来自几个图表的自定义事件以可变的频率轰击一个包含专家顾问和事件处理函数的独立图表。因此,你狭隘的任务结果(EventChartCustom insideOnChartEvent)完全不符合我对自定义事件的工作方案。
这并不复杂,很简单。如果你不能理解,这不是我的问题。 这是一个
它不在 OnChartEvent 里面,而是散落在代码中。 你在为它的运作编造你自己的狭隘约束。那是两个。
同样,如果在mql5-program的队列中已经有一个ChartEvent 事件,或者这样的事件正在被处理,那么这种类型的新事件将不会被放入队列中。
这要么是一个错误,要么是文档错误,要么是条件缺失。
事件成功地全部排好队,没有事件被丢弃。否则我的话题就不会出现。
我想解决我的另一个问题
事件队列溢出对RAM大小有什么影响? 如果事件队列原来是溢出的,那么溢出队列的事件会去哪里?
如果一个事件被丢弃了,那么它就根本没有被排队。记忆不在增长。
吁!这是我想了解的主要内容。既然TheXpert 说只有几MB花在队列本身,那么很可能内存泄漏在其他地方......在没有证明之前,我们就用这个说法吧。
如果出现这种问题,那么事情就非常糟糕了。我认为过度填充的事件队列是寻找内存问题的最后一个地方。
是的,我试图到处寻找。
但要注意的是,在三位被取消资格的专家中,至少有两位是用自定义的事件流工作的(第三位的作者没有回应请求)。Lizar(与自定义事件一起工作)的内存使用率也很高。而tol64的内存消耗极低,因为用户事件的使用频率低于每分钟一次,如果我没有理解错的话。所以,事实证明,你将不得不怀疑随意实现自定义事件概念的效率。 直到你得到一个详尽的答案。
但请注意,在这三个被取消资格的EA中,至少有两个是用自定义事件 流工作的(第三个的作者没有回应请求)。Lizar(与自定义事件一起工作)的内存消耗也很高。而tol64的内存消耗极低,因为用户事件的使用频率低于每分钟一次,如果我没有理解错的话。所以,事实证明,在得到详尽的答案之前,你将不得不怀疑实施自定义事件概念的效率。
这并不复杂,很简单。如果你不能理解,这不是我的问题。
按照我的理解,我写道,这很复杂。否则我就不会去碰它。
它不在OnChartEvent 里面,而是在整个代码中。 你在编造你自己对它的工作方式的狭隘限制。这是二。
是的,是的,EventChartCustom 不是在OnChartEvent 里面,而是,在外面。 现在看一下你自己的代码。
显然,在这段代码中,EventChartCustom不在OnChartEvent 里面,我错得很厉害:)
这要么是错误的,要么是一个bug,要么是文件错误,要么是一个被低估的条件。
所有成功的事件都留在队列中,没有事件被丢弃。否则我的话题就不会出现。
至少还有一个版本:在你的特定情况下,队列根本不会溢出(由于代码效率),所以不存在丢弃事件的事实。
至少还有一个版本:在你的特定情况下,队列根本没有溢出(由于代码效率),所以没有事件被丢弃。
这是我开始演示的不抛弃相同事件的特殊案例
https://www.mql5.com/ru/forum/5091#comment_112780
我在那里写了为什么会发生溢出。
是的,是的,EventChartCustom不是在OnChartEvent 里面,而是,在外面。 现在看一下你自己的代码。
找到根源!我展示了一个问题及其解决方案的演示。 这个EventChart调用可以在代码的任何地方。
而且我们不要忘了一个事实,专家顾问收到了来自指标的事件,这些指标在许多工具和时间框架上运行,如果我没记错的话,总共有大约80个。每个指标都会消耗指标缓冲区 的资源,这就是狗。
你说的是日本人吗?好吧,在我的情况下,它更简单:一个通用指标,有8或15个计算指标缓冲区,在一个时间框架上运行6个工具。也就是说,只有6个指标。理论上说,这样的方案在一周内可以消耗2GB?
请阅读《减少辅助指示器的内存消耗》一文,它可能是有用的。
谢谢,我已经把所有东西都优化到那里了 :)包括在我的记忆中,有这篇文章。我必须等待下一个程度的启蒙 :)
如果专家顾问和指标通过自定义事件一起工作,是否可以分别确定?