测试x64平台的新MQL5编译器--计算速度提高2至10倍 - 页 20

[Aleksey Vyazmikin]

Denis Kirichenko:

优化逻辑。例如，使用数组和循环的工作。尝试将标准值打包成一个数组。并在一个循环中做检查。 也许在7.4万个案例中就不需要了......

当然，从理论上讲，你可以通过一个长的哈希值来生成每个字符串，并且只传递这些哈希值，然后用它来生成所有的东西--但我不确定这是否会很快，而且任务也不简单...

[Aleksey Vyazmikin]

Alexey Kozitsyn:

1.你会在那里看到代码中最 "慢 "的地方。虽然...这是另一个问题，它是否会影响编译...

2.如你所愿：你可以使用案例。有人建议你把它分解成小的功能。打破它，并测试它。是的，当然，代码会变大。但该怎么做。

而在这里，我已经把代码改写成了函数--在附录中。

我马上注意到，以前的代码在编译后占用了14428kb，而新的代码占用了9447kb--我已经对5Mbytes的差异感到惊讶--从哪里来的？

再往前走，通过编译速度，前者

0 error(s), 0 warning(s), 2109302 msec elapsed

新版本

0 error(s), 0 warning(s), 386131 msec elapsed

新版本的编译速度是原来的5.46倍。

而这里是以前的版本在速度方面的情况。

2019.10.15 14:35:47.593 Core 1  pass 0 returned result 1001000.000000 in 0:00:29.555
2019.10.15 14:35:47.595 Core 3  pass 4 returned result 1001000.000000 in 0:00:29.490
2019.10.15 14:35:47.605 Core 2  pass 2 returned result 1001000.000000 in 0:00:29.540
2019.10.15 14:35:47.641 Core 4  pass 6 returned result 1001000.000000 in 0:00:29.541
2019.10.15 14:36:15.511 Core 2  pass 3 returned result 1001000.000000 in 0:00:27.907
2019.10.15 14:36:15.523 Core 1  pass 1 returned result 1001000.000000 in 0:00:27.932
2019.10.15 14:36:15.535 Core 3  pass 5 returned result 1001000.000000 in 0:00:27.942
2019.10.15 14:36:15.537 Core 4  pass 7 returned result 1001000.000000 in 0:00:27.897
2019.10.15 14:36:15.537 Tester  optimization finished, total passes 8
2019.10.15 14:36:15.547 Statistics      optimization done in 0 minutes 58 seconds
2019.10.15 14:36:15.547 Statistics      shortest pass 0:00:27.897, longest pass 0:00:29.555, average pass 0:00:28.725
2019.10.15 14:36:15.547 Statistics      8000 frames (3.14 Mb total, 412 bytes per frame) received
2019.10.15 14:36:15.547 Statistics      local 8 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

新版本。

2019.10.15 14:33:51.458 Core 3  pass 6 returned result 1001000.000000 in 0:01:01.840
2019.10.15 14:33:51.485 Core 2  pass 4 returned result 1001000.000000 in 0:01:01.867
2019.10.15 14:33:51.521 Core 1  pass 2 returned result 1001000.000000 in 0:01:01.903
2019.10.15 14:33:51.524 Core 4  pass 0 returned result 1001000.000000 in 0:01:01.906
2019.10.15 14:34:18.802 Core 3  pass 7 returned result 1001000.000000 in 0:00:27.346
2019.10.15 14:34:18.837 Core 2  pass 5 returned result 1001000.000000 in 0:00:27.354
2019.10.15 14:34:18.892 Core 4  pass 1 returned result 1001000.000000 in 0:00:27.370
2019.10.15 14:34:18.922 Core 1  pass 3 returned result 1001000.000000 in 0:00:27.403
2019.10.15 14:34:18.922 Tester  optimization finished, total passes 8
2019.10.15 14:34:18.932 Statistics      optimization done in 1 minutes 29 seconds
2019.10.15 14:34:18.932 Statistics      shortest pass 0:00:27.346, longest pass 0:01:01.906, average pass 0:00:44.623
2019.10.15 14:34:18.932 Statistics      8000 frames (3.14 Mb total, 412 bytes per frame) received
2019.10.15 14:34:18.932 Statistics      local 8 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

在这里我们看到，代理的第一遍（4个代理）非常慢--我试了很多次--结果是稳定的，但在日志中

2019.10.15 14:38:07.002 Tester  OnTesterInit works too long...

这和现在有什么关系，也许@Renat Fatkhullin 或@Slava 能告诉我为什么会出现这样的效果？

[Aleksey Vyazmikin]

Andrey Khatimlianskii:

该文件是压缩的。读取拉链，解开里面的拉链。这将比传输500MB的EA更快（它也被传输到每个代理）。

然后，它不是在每一个新的通道上再次被解压缩吗？

是的，从文件中读取会比一次性传输....，更快。

[Andrey Khatimlianskii]

Aleksey Vyazmikin:

然后，每次新的通行证不是又被解封了吗？

是的，从文件中读出的速度会不会比单通....？

是的，优化后可能会更慢...但我要检查一下，所有的东西都是为这个而设置的。

[Aleksey Vyazmikin]

Andrey Khatimlianskii:

是的，在优化过程中，它可能会慢一些...但我要检查一下，一切都准备好了。

究竟什么是准备好的--我不明白。

[Andrey Khatimlianskii]

Aleksey Vyazmikin:

究竟什么是准备好的--我不明白。

使用压缩文件。

[Aleksey Vyazmikin]

Andrey Khatimlianskii:

使用压缩文件。

是的，我见过它，但没有在实践中试过它。

对我来说，在数据准备方面的问题更多，即把代码翻译成表格 - 我必须再次处理原始数据...

[Aleksey Vyazmikin]

不幸的是，事实证明，编译器不能应付大的代码--得到了 "EX5写错 "的错误--没有其他错误。如果能在用户手册中写明限制，那就更好了!

[Aleksey Vyazmikin]

做了一个公开版本的EA，现在我正在检查--它是否会被编译--这个过程并不快，但现在你可以看到46%的代码被编译了，已经有36GB的内存被吃掉了。

[Ilyas]

Aleksey Vyazmikin:
做了一个公开版本的EA，现在我正在检查--它是否会被编译--这个过程并不快，但现在你可以看到46%的代码被编译了，已经有36GB的内存被吃掉了。

请给我提供代码以进行调查。
我将检查为什么它的编译速度这么慢，而且消耗这么多内存。