巴解组织的辉煌与贫穷 - 页 5 1234567 新评论 TheXpert 2014.07.06 19:36 #41 meat:在这里,按照我的理解,索引是通过二进制搜索定义的?不,像数组中的直接访问。__________也许我错了,我再考虑一下。 一般来说,没有人阻止你为整个类型的大小创建一个数组并获得持续的访问。(开关只对整体类型起作用)。在你描述的情况下,输入一个枚举是比较方便的。 Alexey Navoykov 2014.07.06 20:36 #42 TheXpert:不,像数组中的直接访问。__________也许我反应过激了,我会再考虑一下。事实上,没有人阻止你为整个类型的大小创建一个数组,并获得持续的访问。(该开关只适用于整体型)。在你描述的情况下,创建一个枚举会更方便。对于该类型的全部价值?不可能!在这种情况下,它需要16Gb的内存(对于一个int类型的数组)。 而且,取整个值有什么意义?计算最大值和最小值之间的差值就足够了。 但无论如何这是一个值得怀疑的情况,因为当数值较大时,我们必须首先与用户协商他愿意为程序分配多少内存。 这就是为什么它只适用于小的键值(或者说是最大和最小值之间的小差值)。这就只剩下二进制搜索 了。 TheXpert 2014.07.06 20:47 #43 meat:这就只剩下二进制搜索了。不,你并不真的需要。简而言之,如果你需要将一个数字映射到一个数字,你需要一个二进制搜索。 如果处理一个数字并将该数字映射到一个数字就足够了,那么你需要一个常数搜索。我理解记忆的问题)),这就是为什么我写到我做得太过了。 Dmitiry Ananiev 2014.07.06 22:06 #44 对比网上和测试器中的分布图,总是有一个问题的空间--为什么?测试员与现实无关...tol64:你是否已经在某个地方给出了更详细的解释(证明)?你必须用证据来支持你的陈述,否则你甚至不会看。;) Vladimir Gomonov 2014.07.07 01:57 #45 C-4: 伙计们,请阅读开关文档。一个好的开关是指其性能不取决于选择数量的开关式过渡。1个选择,100个或1000个--其过渡率将是恒定的。 华感谢,很好的参考资料,读后很高兴,受益匪浅。 Anatoli Kazharski 2014.07.07 07:12 #46 dimeon:对比网上和测试器中的分布图,总是有一个问题的空间--为什么?测试员与现实没有关系...为了引起注意。开 一个新的主题,更详细地介绍你的问题。在真实中展示如何,在测试器中展示如何。提出你对这个问题的解决方案。否则,它将继续 "没有机会,没有选择"。) Vasiliy Sokolov 2014.07.07 09:48 #47 Vinin:证据将来自于另一方。或者再一次只是说说而已。总的来说,我只对事实感兴趣。 虽然我已经知道OOP比较慢,但它提供了相当具体的便利。如同承诺的那样,我正在布置一个项目的剖析结果。(请原谅我,有些功能被涂黑了,因为这些代码不是为一般公众准备的)。首先,我要说的是,这是一个真正的OOP-项目,对源数据进行了强有力的转换。在其中使用OOP的想法被发挥到了极致。例如,它完全不使用类外的全局变量、数组、函数--因为它们不够OOP。为了使其发挥作用,我们需要在整个期间进行的订单和交易的历史。解析6014笔交易和6599笔订单只需要3.1秒,或每笔交易0.25毫秒,部署所有交易、订单和头寸的RAM需要约13MB,或平均每笔交易1千字节。- 我认为这对一个OOP应用程序来说是一个非常好的结果。2014.07.07 12:44:33.464 TestMA (AUDCAD,H1) 我们开始了。历史交易(6014)和订单(6599)的解析工作完成了3.104秒。使用了13MB内存。但是,让我们看一下初始化应用程序时的时间结构。我们看到,大部分时间都花在调用AddNewDeal函数上。这是一个复合函数,真正的工作被委托给RecalcValues(57%)。它又由系统函数组成,如HistoryOrderGetInteger。请注意,这些函数的调用时间大致相等。请注意,这是整个函数传输的结束。在你进行这些计算之前,你需要再通过一打中间的OOP-方法,其中一些也是虚拟的。但它们的运行时间可以忽略不计,而且在剖析器中,它们处于列表的后半部分。作为一个100%的OOP应用程序,我很容易跟踪时间关键的代码部分,而且我可以非常有效地找到新的方法来提高性能。我已经知道,剩下的部分(43%)是由调用CArray.Resize()的80-90%组成的。有一些地方的代码没有被优化,数组重新分区的发生频率超过了必要的范围。我可以轻松地重写这些OOP模块,并将性能提高25%-30%。如果没有OOP,这将更难做到,因为每个函数都有可能涉及到无限多的相互关系,要计算这样一个函数的变化所带来的后果就变得更加困难。结果发现,即使是一个复杂的OOP项目也会被带到基本系统功能的性能极限。但 如果没有OOP,要实现这样的生产力将更加困难,因为会有很多函数,你迟早会犯错误:你会做出不必要的调用或非优化的双胞胎,或太复杂和繁琐的实现。 Mykola Demko 2014.07.07 10:07 #48 dimeon:对比网上和测试器中的分布图,总是有一个问题的空间--为什么?在测试器中,它与现实毫无关系... 关于交易、自动交易系统和策略测试的论坛 OOP的光荣与龌龊 tol64, 2014.07.07 09:12 为了引起注意。打 开一个新的主题,更详细地介绍你的问题。显示它在现实生活中是如何的,以及它在测试器中是如何的。为这个问题提出你自己的解决方案。否则,它将继续 "没有机会,没有选择"。)+++todimeon - 打开一个主题,你会了解到很多论点,为什么它不能,为什么它应该。 Alexey Navoykov 2014.07.07 14:28 #49 C-4:如同承诺的那样,我发布了对一个项目进行分析的结果。(没有不敬的意思,但有些功能是被掩盖的,因为代码不是为一般公众准备的)。...这一切有什么意义? 你没有引用你的函数的代码(除非你算上一些撕裂的片段)。 那么有什么可讨论的呢? 这个主题是专门关于比较OOP和程序化编程的性能。而事实上,你的秘密功能应该是执行一些工作,把一些东西委托给某个地方,花一些时间,而你巧妙地处理这一切--当然,我们为你感到无比高兴,但这些信息有什么用,如果我们不看密码。 Renat Fatkhullin 2014.07.07 14:33 #50 meat:这一切有什么意义呢? 你没有引用你的函数的代码(除非你算上一些撕裂的片段)。 那么要讨论什么呢? 这里的主题是关于比较OOP和程序化编程的性能。而事实上,你的秘密功能应该是执行一些工作,把一些东西委托给某个地方,花一些时间,而你巧妙地管理这一切--当然,我们为你感到难以置信的高兴,但如果我们不看密码,这些信息有什么用。他表明,直接呼叫或虚拟呼叫在实际项目 中没有效果。通过对一个真实的OOP项目进行剖析的例子,我将表明它在极限状态下的性能趋向于系统函数调用性能绝大多数的费用是在系统函数调用中产生的,MQL程序的大部分时间都花在这里。与有效载荷相比,安排通话的成本可以忽略不计。 1234567 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
在这里,按照我的理解,索引是通过二进制搜索定义的?
不,像数组中的直接访问。
__________
也许我错了,我再考虑一下。
一般来说,没有人阻止你为整个类型的大小创建一个数组并获得持续的访问。(开关只对整体类型起作用)。
在你描述的情况下,输入一个枚举是比较方便的。
不,像数组中的直接访问。
__________
也许我反应过激了,我会再考虑一下。
事实上,没有人阻止你为整个类型的大小创建一个数组,并获得持续的访问。(该开关只适用于整体型)。
在你描述的情况下,创建一个枚举会更方便。
对于该类型的全部价值?不可能!在这种情况下,它需要16Gb的内存(对于一个int类型的数组)。 而且,取整个值有什么意义?计算最大值和最小值之间的差值就足够了。 但无论如何这是一个值得怀疑的情况,因为当数值较大时,我们必须首先与用户协商他愿意为程序分配多少内存。 这就是为什么它只适用于小的键值(或者说是最大和最小值之间的小差值)。这就只剩下二进制搜索 了。
这就只剩下二进制搜索了。
不,你并不真的需要。简而言之,如果你需要将一个数字映射到一个数字,你需要一个二进制搜索。 如果处理一个数字并将该数字映射到一个数字就足够了,那么你需要一个常数搜索。
我理解记忆的问题)),这就是为什么我写到我做得太过了。
对比网上和测试器中的分布图,总是有一个问题的空间--为什么?测试员与现实无关...
你是否已经在某个地方给出了更详细的解释(证明)?
你必须用证据来支持你的陈述,否则你甚至不会看。;)
伙计们,请阅读开关文档。一个好的开关是指其性能不取决于选择数量的开关式过渡。1个选择,100个或1000个--其过渡率将是恒定的。
对比网上和测试器中的分布图,总是有一个问题的空间--为什么?测试员与现实没有关系...
证据将来自于另一方。或者再一次只是说说而已。
总的来说,我只对事实感兴趣。
虽然我已经知道OOP比较慢,但它提供了相当具体的便利。
如同承诺的那样,我正在布置一个项目的剖析结果。(请原谅我,有些功能被涂黑了,因为这些代码不是为一般公众准备的)。
首先,我要说的是,这是一个真正的OOP-项目,对源数据进行了强有力的转换。在其中使用OOP的想法被发挥到了极致。例如,它完全不使用类外的全局变量、数组、函数--因为它们不够OOP。为了使其发挥作用,我们需要在整个期间进行的订单和交易的历史。解析6014笔交易和6599笔订单只需要3.1秒,或每笔交易0.25毫秒,部署所有交易、订单和头寸的RAM需要约13MB,或平均每笔交易1千字节。- 我认为这对一个OOP应用程序来说是一个非常好的结果。
但是,让我们看一下初始化应用程序时的时间结构。
我们看到,大部分时间都花在调用AddNewDeal函数上。这是一个复合函数,真正的工作被委托给RecalcValues(57%)。它又由系统函数组成,如HistoryOrderGetInteger。
请注意,这些函数的调用时间大致相等。
请注意,这是整个函数传输的结束。在你进行这些计算之前,你需要再通过一打中间的OOP-方法,其中一些也是虚拟的。但它们的运行时间可以忽略不计,而且在剖析器中,它们处于列表的后半部分。
作为一个100%的OOP应用程序,我很容易跟踪时间关键的代码部分,而且我可以非常有效地找到新的方法来提高性能。我已经知道,剩下的部分(43%)是由调用CArray.Resize()的80-90%组成的。有一些地方的代码没有被优化,数组重新分区的发生频率超过了必要的范围。我可以轻松地重写这些OOP模块,并将性能提高25%-30%。如果没有OOP,这将更难做到,因为每个函数都有可能涉及到无限多的相互关系,要计算这样一个函数的变化所带来的后果就变得更加困难。
结果发现,即使是一个复杂的OOP项目也会被带到基本系统功能的性能极限。但 如果没有OOP,要实现这样的生产力将更加困难,因为会有很多函数,你迟早会犯错误:你会做出不必要的调用或非优化的双胞胎,或太复杂和繁琐的实现。
对比网上和测试器中的分布图,总是有一个问题的空间--为什么?在测试器中,它与现实毫无关系...
关于交易、自动交易系统和策略测试的论坛
OOP的光荣与龌龊
tol64, 2014.07.07 09:12
为了引起注意。打 开一个新的主题,更详细地介绍你的问题。显示它在现实生活中是如何的,以及它在测试器中是如何的。为这个问题提出你自己的解决方案。否则,它将继续 "没有机会,没有选择"。)+++
todimeon - 打开一个主题,你会了解到很多论点,为什么它不能,为什么它应该。
如同承诺的那样,我发布了对一个项目进行分析的结果。(没有不敬的意思,但有些功能是被掩盖的,因为代码不是为一般公众准备的)。
...
这一切有什么意义? 你没有引用你的函数的代码(除非你算上一些撕裂的片段)。 那么有什么可讨论的呢? 这个主题是专门关于比较OOP和程序化编程的性能。而事实上,你的秘密功能应该是执行一些工作,把一些东西委托给某个地方,花一些时间,而你巧妙地处理这一切--当然,我们为你感到无比高兴,但这些信息有什么用,如果我们不看密码。
这一切有什么意义呢? 你没有引用你的函数的代码(除非你算上一些撕裂的片段)。 那么要讨论什么呢? 这里的主题是关于比较OOP和程序化编程的性能。而事实上,你的秘密功能应该是执行一些工作,把一些东西委托给某个地方,花一些时间,而你巧妙地管理这一切--当然,我们为你感到难以置信的高兴,但如果我们不看密码,这些信息有什么用。
他表明,直接呼叫或虚拟呼叫在实际项目 中没有效果。
通过对一个真实的OOP项目进行剖析的例子,我将表明它在极限状态下的性能趋向于系统函数调用性能
绝大多数的费用是在系统函数调用中产生的,MQL程序的大部分时间都花在这里。与有效载荷相比,安排通话的成本可以忽略不计。