错误、漏洞、问题 - 页 1625

[Alexey Navoykov]

Vladislav Andruschenko:

mt4的编译时间为888毫秒。

同一个项目在MT5中的编译速度为4103ms。

好吧，看来问题与v5有关。 4.5的差别不小。尽管为了使情况完整，最好用旧的编译器（1159）检查一下，如果你有的话（或者我可以下载）。 但也许你必须对你的代码做一些修正。

[Alexey Viktorov]

-Aleks-:

我没有钱买MT5--我交易美分账户，DC不急于为五分钱开账户。

不够仔细看。https://www.mql5.com/ru/forum/88768/page2#comment_2587760

[coderex]

Alexey Navoykov:

我想再次提出MQL5编译缓慢的问题。 大约三个月前，我试图提出这个问题，但没有得到理解，显然我的论点不够有说服力。 因此，我回滚到旧的构建（1159），它几乎立即编译了所有东西（而用新的编译器，我的项目在20秒内编译完毕）。

所以一周前我一直在尝试切换到一个新的版本。 我想 "忘掉20秒吧，为了新的东西我可以忍受它"。 当然我不得不调整一下代码以符合新的条件，这发现了新编译器的几个错误（关于这一点我在这里报告）。结果是，我的项目已经编译了30秒！我不知道这是否与项目的复杂性有关，还是与编译器多了一个 "复杂性 "有关，但它就是不合适了。

这个项目包含大约700Kb的源代码，它是一个包含几十个mqh的专家顾问。 一切都是OOP。 人们早些时候给我写信说，速度慢可能是由大型函数造成的。我有几个。 好吧，我把它们分割成小部分，它们没有影响。

最令人吃惊的是，这个超长的汇编根本没有任何用处。程序的速度与旧的编译器相同，我专门测量过。 这只需要一句话："为什么？"。

我有一种强烈的感觉，编译器中存在一个错误/故障，因为它在空旷的空间中闲庭信步。 否则我怎么解释一个绝对空旷的脚本，只有OpenStart() { }函数的编译超过400毫秒的事实呢？难以想象，编译/优化一个空的脚本会花费这么长的时间。 那么，通过向其中添加小的函数和类，你可以看到编译时间增长的速度。

我想说的是，我的硬件当然远远不够强大--Core i5U。 但这并不妨碍我的项目在旧的编译器上1-2秒内完成编译。 尊敬的是，假人在那里很快就被编译了。

我还要指出。编译器不仅完全缺乏对先前编译的片段的缓存，而且甚至缺乏一个微不足道的检查，以确保源代码是相同的。 也就是说，你编译你的项目，然后再次点击 "编译 "按钮，不做任何修改，再次等待同样的30秒。 这有多好...

我想听听MT开发人员和论坛用户的意见，他们正在处理大型项目（只有我有这个问题吗？），编译需要多长时间等等。

我的项目 有十几个源文件，像你一样，而且都是OOP，虽然我不会声称有20秒，但我经常看到超过11-14秒。然而，某种缓存正在发生，因为如果你不改变任何东西，时间就会以任何不可预测的方向变化1-2秒。我不是在比较使用新旧编译器构建项目的情况，因为旧的编译器构建一切都快得多。我想开发商自己也看到了这一点，总有一天他们会解决这个问题的:)他们每个月发布几个新的运行，这不是没有原因的--这意味着他们看到了一些东西，并修复了它。

[Vasilii Polovnikov]

终端版本和比特率

v.1375，64位

问题描述。

升级到最新版本后，代理在优化过程中通过第一个1900-2100次后就冻结了。更新前一切正常，所有参数和EA代码都一样。

行动的顺序

优化开始。开业经纪人。真实账户。工具。Si Splice, Vtb Splice, Si 9.16, Vtb 9.16（我没有试过其他的）。间隔：月、分钟、15分钟。开盘价或OHLC。

结果。

本地和远程代理在2000次通过后实际上冻结了，CPU负载，每10分钟变化约0.01%。14名代理人。

预期的结果

与之前的构建一样，进行了优化演练。

其他信息

关于我：经验丰富的.net MQL5程序员

我到处查看了日志。我把它们与上一次建造的日志进行了比较。我没有遇到任何问题或错误。历史的质量是好的。

[Alexey Navoykov]

coderex:

然而，有一些缓存正在进行，因为如果你不改变任何东西，时间会以任何不可预测的方向 变化1-2秒。

:) 这显然只是一个错误，是系统中其他进程的影响，再加上磁盘缓存。 无论如何，10-15%根本不是指标，缓存就是为了这个。

我不会比较用新旧编译器构建项目的情况，因为旧编译器构建一切都要快得多。我想开发人员自己也看到了这一点，并会在某个时候修复它 :)每个月都有几个新的运行，这不是没有原因的，这意味着他们看到了一些东西，并修复了它。

新的测试版的发布是因为人们抱怨各种bug，但如果bug是他们修复的一个坚实的理由，所有其他的......你必须要说服他们很长时间。甚至当它似乎清楚地带来了所有的论据，清楚地勾勒出了尽可能清晰的画面时，他们仍然抵制，不择手段:)我在这里和3个月前一样试图说服他们，但没有人支持。

而且我看到，只有少数人在大项目 中使用MQL，他们可能不会因为多几秒钟而去管小项目。

顺便问一下，你的CPU是什么类型的？

[coderex]

Alexey Navoykov:

...他们将尽其所能 :)

这就是为什么我不想证明什么 :) 此外，pluses项目 需要更长的时间来构建，尽管它们大得多，但我习惯于pluses在几分钟内构建可执行文件或库文件，而带有目录结构的几个文件的项目需要几十分钟 :) 而等待10-20秒不是问题...

[Aleksey Vyazmikin]

Alexey Viktorov:
没有仔细看。https://www.mql5.com/ru/forum/88768/page2#comment_2587760

该链接没有给出感兴趣的信息--要具体。

[Alexey Da]

ProfitTraderRU:

终端版本和比特率

v.1375，64位

问题描述。

升级到最新版本后，在优化过程中，代理在通过第一个1900-2100次后就冻结了。更新前一切正常，所有参数和EA代码都一样。

行动的顺序

优化开始。开业经纪人。真实账户。工具。Si Splice, Vtb Splice, Si 9.16, Vtb 9.16（我没有试过其他的）。间隔：月、分钟、15分钟。开盘价或OHLC。

结果。

本地和远程代理在2000次通过后实际上冻结了，CPU负载，每10分钟变化约0.01%。14名代理人。

预期的结果

与之前的构建一样，进行了优化演练。

其他信息

关于我：经验丰富的.net MQL5程序员

我到处查看了日志。我把它们与上一次建造的日志进行了比较。我没有遇到任何问题或错误。历史的质量是好的。

这种行为是否发生在任何专家顾问身上？

如果能有这些日志就好了。请向服务台提交一份票据。

[Vasilii Polovnikov]

我只测试了我的EA。在以前的构建中，它们被正常优化。

我已经向Serviced提出了申请。相信我，日志中没有任何异常（看到以前和现在的构建日志）。

[Vasilii Polovnikov]

Alexey Da:

终端日志很好，更有趣的是策略测试员和测试代理 的日志。

+ 在您的票据中至少附上您的专家顾问的EX5（我们将在研究后删除它）+优化过程中使用的参数描述。

好的，谢谢你。