巴解组织的辉煌与贫穷 - 页 5

新评论
 
meat:

在这里，按照我的理解，索引是通过二进制搜索定义的？

不，像数组中的直接访问。

__________

也许我错了，我再考虑一下。

一般来说，没有人阻止你为整个类型的大小创建一个数组并获得持续的访问。(开关只对整体类型起作用)。

在你描述的情况下，输入一个枚举是比较方便的。

 
TheXpert:

不，像数组中的直接访问。

__________

也许我反应过激了，我会再考虑一下。

事实上，没有人阻止你为整个类型的大小创建一个数组，并获得持续的访问。(该开关只适用于整体型)。

在你描述的情况下，创建一个枚举会更方便。

对于该类型的全部价值？不可能!在这种情况下，它需要16Gb的内存（对于一个int类型的数组）。 而且，取整个值有什么意义？计算最大值和最小值之间的差值就足够了。 但无论如何这是一个值得怀疑的情况，因为当数值较大时，我们必须首先与用户协商他愿意为程序分配多少内存。 这就是为什么它只适用于小的键值（或者说是最大和最小值之间的小差值）。这就只剩下二进制搜索 了。

 
meat:

这就只剩下二进制搜索了。

不，你并不真的需要。简而言之，如果你需要将一个数字映射到一个数字，你需要一个二进制搜索。 如果处理一个数字并将该数字映射到一个数字就足够了，那么你需要一个常数搜索。

我理解记忆的问题）），这就是为什么我写到我做得太过了。

 

对比网上和测试器中的分布图，总是有一个问题的空间--为什么？测试员与现实无关...

tol64:

你是否已经在某个地方给出了更详细的解释（证明）？

你必须用证据来支持你的陈述，否则你甚至不会看。;)

 
C-4:
伙计们，请阅读开关文档。一个好的开关是指其性能不取决于选择数量的开关式过渡。1个选择，100个或1000个--其过渡率将是恒定的。
华感谢，很好的参考资料，读后很高兴，受益匪浅。
 
dimeon:

对比网上和测试器中的分布图，总是有一个问题的空间--为什么？测试员与现实没有关系...

为了引起注意。开 一个新的主题，更详细地介绍你的问题。在真实中展示如何，在测试器中展示如何。提出你对这个问题的解决方案。否则，它将继续 "没有机会，没有选择"。)
 
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，要实现这样的生产力将更加困难，因为会有很多函数，你迟早会犯错误：你会做出不必要的调用或非优化的双胞胎，或太复杂和繁琐的实现。

 
dimeon:

对比网上和测试器中的分布图，总是有一个问题的空间--为什么？在测试器中，它与现实毫无关系...

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

OOP的光荣与龌龊

tol64, 2014.07.07 09:12

为了引起注意。打 开一个新的主题，更详细地介绍你的问题。显示它在现实生活中是如何的，以及它在测试器中是如何的。为这个问题提出你自己的解决方案。否则，它将继续 "没有机会，没有选择"。)

+++

todimeon - 打开一个主题，你会了解到很多论点，为什么它不能，为什么它应该。

 
C-4:

如同承诺的那样，我发布了对一个项目进行分析的结果。(没有不敬的意思，但有些功能是被掩盖的，因为代码不是为一般公众准备的）。

...

这一切有什么意义？ 你没有引用你的函数的代码（除非你算上一些撕裂的片段）。 那么有什么可讨论的呢？ 这个主题是专门关于比较OOP和程序化编程的性能。而事实上，你的秘密功能应该是执行一些工作，把一些东西委托给某个地方，花一些时间，而你巧妙地处理这一切--当然，我们为你感到无比高兴，但这些信息有什么用，如果我们不看密码。

 
meat:

这一切有什么意义呢？ 你没有引用你的函数的代码（除非你算上一些撕裂的片段）。 那么要讨论什么呢？ 这里的主题是关于比较OOP和程序化编程的性能。而事实上，你的秘密功能应该是执行一些工作，把一些东西委托给某个地方，花一些时间，而你巧妙地管理这一切--当然，我们为你感到难以置信的高兴，但如果我们不看密码，这些信息有什么用。

他表明，直接呼叫或虚拟呼叫在实际项目 中没有效果。

通过对一个真实的OOP项目进行剖析的例子，我将表明它在极限状态下的性能趋向于系统函数调用性能

绝大多数的费用是在系统函数调用中产生的，MQL程序的大部分时间都花在这里。与有效载荷相比，安排通话的成本可以忽略不计。

1234567
新评论
原因: