我怎样才能持续地通过列举？ - 页 3

新评论
 
Alexey Navoykov:

这里显示的例子（案例1：返回值1；案例2：返回值2；案例3：返回值3。一个适当的人可以将所有的值放入一个数组中，然后通过其索引获得所需的值。 而对于反向任务，他/她会使用二进制搜索。

我两手赞成用数组编写漂亮的代码。但在写一个比普通的更快的NormalizeDouble 时，我遇到了一个优化器效应--通过const-array的漂亮解决方案比繁琐的switch-case解决方案慢得多。我留下了第二种变体，因为NormalizeDouble在测试器中被大量使用。我把它放到指标里，不看这个怪物。但回测运行得更快。
 
fxsaber:
我两手赞成使用数组的漂亮代码。但在编写比普通的NormalizeDouble更快的时候，我遇到了优化器的影响--通过const-array的漂亮解决方案比通过switch-case的繁琐解决方案慢得多。我留下了第二种变体，因为NormalizeDouble在测试器中被大量使用。我把它放到指标里，不看这个怪物。但回测运行得更快。

我记得曾经有一个讨论switch的话题，开发者们只讨论了作为二进制搜索 的实现，这当然要比通过计算索引的简单访问慢得多。但现在他们似乎做得更明智了：如果一个步骤是常数，就计算索引，否则就进行二进制搜索。 当然，本地实现总是比封装器的快。

当然，这取决于你的优先事项。但我认为，如果速度如此重要，以至于你准备发明拐杖，那么你也应该放弃OOP和MQL；）尽管我确信在适当的编码下，速度上的差异不会那么明显。 在测试测量中，你只是在一个循环中把一个函数跳动了数百万次。而你在真正的代码中更合理地使用它，不是吗？

 
Alexey Navoykov:

我记得曾经有一个讨论switch的话题，开发者们只讨论了作为二进制搜索的实现，当然这要比通过计算索引的简单访问慢得多。但现在他们似乎做得更明智了：如果步骤是恒定的，那么就计算索引，否则就进行二进制搜索。 当然，本地实现总是比封装器的快。

编译器，如果它不是哑巴的话，将不得不把const-array和它的唯一类型引用的索引变成开关代码。

当然，你可能不得不这样做，这取决于你的优先事项。但我认为，如果速度是如此重要，以至于你准备发明拐杖，那么你应该放弃OOP和MQL一般；）尽管我确信在正确的编码下，速度的差异不会那么大。 在测试测量中，你只是在一个函数的循环中赛跑数百万次。而在真正的代码中，你会更理性地使用它，不是吗？

速度并不关键，但当我写得不理性时，我就会感到不适。当然，完全不使用OOP 是不理性的。总之，看看你在kodobase中布置的微薄的努力，已经很多天没有计算了。在那里你会明白以同样的NormalizeDouble形式出现的拐杖在哪里。它是来自开发者有时不合理的实施的随机事实的结果。
 
fxsaber:
 编译器，如果它不笨的话，应该把const-array和它唯一的类型引用的索引变成开关代码。

那么阵列只是一个常量？静态的情况如何？为什么是 "切换代码 "呢？ 这是一个简单的操作：比较索引值和数组/枚的大小，如果小于这个值，得到所需元素的地址，作为数组地址+索引，然后从那里读取值。我以为这样的废话必须平等地编译。

总之，看看kodobase中的微薄之力，我已经布置好了，很多天都没有计算过。在那里你会明白，以同样的NormalizeDouble形式出现的拐杖在哪里。这是一个偶然的事实，来自开发者有时不合理的实施。
顺便说一下，你是在多长时间前进行这些比较的？也许那时的编译器还很 "笨"？
 
Alexey Navoykov:

那么阵列只是一个常量？静态的情况如何？为什么是 "切换代码 "呢？ 这是一个简单的操作：比较索引值和数组/枚的大小，如果小于这个值，得到所需元素的地址，作为数组地址+索引，然后从那里读取值。我以为这样的废话必须以同样的方式进行编译。

我不记得是否可以用常量方法创建静态数组，当然不可以。作为一个原则问题，我是在做常数而不是静态。寄希望于编译器的智慧。编译之后，内脏中根本不应该有任何阵列的提示。statik是一个比const复杂得多的结构。 这就是为什么我确信编译器会无法应付statik的原因。但我必须要试一试。

我不太清楚你说的 "努力 "是什么意思。 顺便问一下，你是在多长时间前进行这些比较的？也许那时的编译器还很 "笨"？
只要有一位版主按下几个按钮，批准在kodobase中发布代码，就可以看到这些努力。为自己做了一个方便的解决方案，没有考虑性能问题，在Build 1383 32位中得到了几乎一个数量级的增益。
 
fxsaber:

我不太记得静态数组是否可以变成常数。方法--肯定不行。作为一个原则问题，我是在做常数，而不是静态的。寄希望于编译器的智慧。编译之后，内脏中根本不应该有任何阵列的提示。statik是一个比const复杂得多的结构，所以我确信编译器会无法处理statik。但我必须要试一试。

哦，好吧，这解释了它。你不应该依赖编译器的过度智能，它为你进一步优化了一个糟糕的设计方案。 如果你自己太懒了，不能正确地做，说 "静力学要复杂得多"（尽管那里有什么复杂的，我不明白），那么为什么指责编译器呢？

 
Alexey Navoykov:

哦，好吧，这解释了它。你不应该依赖编译器的过度智能，因为它将为你优化一个设计不良的解决方案。 如果你自己太懒，不能正确地做，说 "静态的要复杂得多"（虽然那里有什么复杂的，我不明白），那么为什么指责编译器？

我在数组中加入了静态。它的工作速度几乎是开关的三倍!把那个开关扔掉。谢谢你的提示!
 
fxsaber:
我在数组中加入了静态。它的工作速度几乎是开关的三倍!扔掉这个开关。谢谢你的提示!

不客气，这将是未来的一个教训，一个人在跑去发明拐杖之前，应该考虑7次）。

现在发现，我赞美了这个开关，或者说是它的开发者太早了。 所以所有的东西都只能通过二进制搜索 来实现，即使枚举的时候是多倍的。 这可不好。

 
Alexey Navoykov:

不客气，这将是未来的一个教训，在跑来跑去发明拐杖之前要考虑7次 )

比标准的NormalizeDouble(build 1395)几乎快四倍...是开发商的一个拐杖。

 
fxsaber:
比标准的NormalizeDouble(build 1395)几乎快四倍...是开发商的一个拐杖。

每个人都不是没有罪的 )
12345678
新评论