绕过MQL4和MQL5中的Digits()，获取任何数字的小数位数（不仅仅是引号）。 - 页 21

[fxsaber]

Nikolai Semko:
暂时在路上。你可以自己试试。我们的想法是用不同大小的数组结构的联合体，例如10、100、1000、10000......。

这将使循环缩短几个数量级，并使ArrayCopy的调用 数量减少几个数量级。

这应该接近于memcopy的变体。

这个想法被采用了。在这种情况下

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

在MQL4和MQL5中绕过Digits()获得任何数字的小数位数（不仅仅是引号）。

fxsaber, 2018.12.08 16:25

当然也尝试了不同的尺寸。由于某些原因，不影响结果。

你可以在源代码中看到一切。

[Nikolai Semko]

fxsaber:

这个想法被采用了。这样一来

你可以在资料手册中看到一切。

是的，查过了。奇怪的是，它没有任何效果。

[fxsaber]

Nikolai Semko:
是的，查过了。奇怪的是，它没有任何效果。

在源代码中，有一行是控制大小的

#define  CONVERT_AMOUNT 128

你可以改变这个值，看看结果。如果数值大于一百，速度就不会增加。其实这很容易解释，因为所有相同数量的元素都被复制在一起了。并且消除了与小规模复制部分相关的减速现象。

[Nikolai Semko]

fxsaber:

恐怕我们已经被锁定 在最大性能上了。

是的，我同意。
我试了一下 - 与你的TicksToIntArray_fxsaber4/IntArrayToTicks_fxsaber4的结果相同

[Ilya Malev]

Andrey Khatimlianskii:

你有源代码，你可以自己测量它。

所以要测量它。我很确定我不知道，所以我不认为有必要在这篇文章或测量上浪费时间。

[Nikolai Semko]

fxsaber:

恐怕我们已经 达到了性能的极限。

说实话，我非常惊讶，他们竟然能做到如此接近memcpy。这是不可能的。有些事情是不对的。

[Nikolai Semko]

fxsaber:

恐怕我们已经被困在 最大的性能上了。

我想我明白你的一个非常严重的误判。
你的BANCH选择至少50个绝对相同的运行。
但是，编译器是一个大笨蛋，而且很懒。它不会做50次同样的工作，并会优化代码。这就是为什么你至少应该在每次运行时改变阵列。或者你可以用1代替50，并增加测试的数量。那么结果就会截然不同，更加客观。

2018.12.09 13:55:43.048 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9813963
2018.12.09 13:55:43.048 StructToArray__2        TicksToIntArray_thexpert
2018.12.09 13:55:43.296 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 247579
2018.12.09 13:55:43.296 StructToArray__2        IntArrayToTicks_thexpert
2018.12.09 13:55:43.544 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 247840
2018.12.09 13:55:43.634 StructToArray__2        true
2018.12.09 13:55:43.766 StructToArray__2        
2018.12.09 13:55:43.766 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9814108
2018.12.09 13:55:43.766 StructToArray__2        TicksToIntArray_fxsaber4
2018.12.09 13:55:44.118 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 351847
2018.12.09 13:55:44.118 StructToArray__2        IntArrayToTicks_fxsaber4
2018.12.09 13:55:44.452 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 334011
2018.12.09 13:55:44.548 StructToArray__2        true
2018.12.09 13:55:44.692 StructToArray__2        
2018.12.09 13:55:44.692 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9814108
2018.12.09 13:55:44.692 StructToArray__2        TicksToIntArray_semko
2018.12.09 13:55:45.037 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 344707
2018.12.09 13:55:45.037 StructToArray__2        IntArrayToTicks_semko
2018.12.09 13:55:45.373 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 336193
2018.12.09 13:55:45.462 StructToArray__2        true

当与memcpy相比，差异为40%时，就更有说服力了

我想知道压缩阵列是否会有影响。一个数组的ticks可以被压缩10-12倍。唯一的问题是，这是否会节省通过资源发送和接收的结果时间。

[fxsaber]

Nikolai Semko:

我想我明白了你的一个非常严重的误判。
你的BANCH选择了50个绝对相同的运行中的最小值。
但编译器是一个大聪明，而且很懒。它不会做同样的工作50次，它将优化代码。

代码是以这样的方式编写的，它将完全做它应该做的事情。编译器将无法影响memcpy的 速度，但通过的结果如下

循环的一次通过

https://www.mql5.com/ru/forum/287618/page18#comment_9813963
TicksToIntArray_thexpert
Time[TicksToIntArray(TicksIn,Array)] = 235285
IntArrayToTicks_thexpert
Time[IntArrayToTicks(Array,TicksOut)] = 192509
true

满分50分

https://www.mql5.com/ru/forum/287618/page18#comment_9813963
TicksToIntArray_thexpert
Time[TicksToIntArray(TicksIn,Array)] = 80970
IntArrayToTicks_thexpert
Time[IntArrayToTicks(Array,TicksOut)] = 81103
true

[Nikolai Semko]

fxsaber:

代码是以这样一种方式编写的，它将准确地做你想做的事。编译器无法影响memcpy的速度，但通过的结果是

循环的一次通过

50人中。

但是，为什么会发生这种情况呢？当然，编译器不能影响执行memcpy 的过程，但它可以拒绝执行它，从第一次计算中拉出预先存储的结果，如果它了解到在循环过程中没有一个计算参数发生变化。这就是我自己组织编译器来修复程序逻辑的方法。

[Andrey Khatimlianskii]

Ilya Malev:

所以要测量它。我很确定我不知道，所以我不认为有必要在这篇文章或测量上浪费时间。

我没有必要这样做。