错误、漏洞、问题 - 页 2668

[fxsaber]

Sergey Dzyublik:

问题是，如果我保留内存并一次创建数组元素，所需时间比一次创建所有 元素要长很多倍。

在代码中没有注意到这一点。解释一下，因为只有一个如果触发了，如果尺寸没有变化，就退出。

[Sergey Dzyublik]

fxsaber:

在代码中没有注意到这一点。解释一下，因为只有一个如果触发了，如果尺寸没有变化，就退出。

对上述代码#2666 的解释

test1，在第一次调用时一次性创建了所有元素，ArrayResize的其余调用都是 "闲置 "的。
ArrayResize调用的总数==array_size。

      T class_array[];
      for(int i = 1; i <= array_size; i++){
         ArrayResize(class_array, array_size);
      }

test2，创建了一个元素并为另一个array_size-1元素保留了空间，其余对ArrayResize的调用是为了从先前保留的内存中创建+1元素的阵列。
ArrayResize == array_size的总调用次数。

      T class_array[];
      ArrayResize(class_array, 1, array_size - 1);
      for(int i = 2; i <= array_size; i++){
         ArrayResize(class_array, i);
      }

*原代码中存在一个错误（+-一个元素的差异）。该代码已被更新。
问题是：为什么测试2的算法对结构来说比测试1慢7倍，对类和int来说慢2倍？

[Alain Verleyen]

Sergey Dzyublik :

在我这边，比较的结果是它应该是这样的。
我知道有多少元素将被放入数组中，而且，我没有一次性创建它们，而是为未创建的元素保留内存。
问题是，如果我保留内存并一个一个地创建数组项目，需要的时间比一次性创建要长很多倍。
因此，对于结构来说，它的速度要慢7倍。
而对于类和int数据类型，它的速度要慢两倍。

这是一个非常大的区别，我相信如果开发者愿意，他们可以消除这种区别。

好吧，在这种情况下，我同意只应该有较低的管理费。

但是，在我看来，问题更在于你的比较方式。test1中的循环可能被编译器优化和删除，甚至可能是下一个。

 for ( ulong ii= 0 ;ii<count&&! _StopFlag ;ii++)

试试剖析器，你只会看到一个小的差异。

[Alain Verleyen]

没有用剖析器 进行编译器优化。

[fxsaber]

Sergey Dzyublik:

问题是：为什么对于结构来说，test2比test1慢7倍，而对于类和int来说慢2倍？

默认的构造函数。

[Sergey Dzyublik]

Alain Verleyen:

test1中的循环可能已被编译器优化并删除了

如果你在Debug模式下运行上述代码#2666，你会看到与前面得到的结果相似，因为减速是由ArrayResize函数的工作引起的，而不是由用户代码的优化引起的。
调试模式的执行没有任何优化：代码中写的内容被执行，执行的内容只是用户断点的nop-types，在指令之间插入。

[Aleksei Skrypnev]

没有收到关于新服务的短信，确认通过短信开立模拟账户。更多细节请点击这里。

https://www.mql5.com/ru/forum/334179#comment_1529250

[Alain Verleyen]

Sergey Dzyublik :

如果你在调试模式下运行上述代码#2666，你会看到与前面得到的结果相似，因为滞后的是ArrayResize函数的工作，而不是对用户代码的优化。
调试模式的执行没有任何优化：代码中所写的内容被执行，nops只是在用户断点的指令之间被插入。

如帖子#26674 所示，使用ArrayResize()没有问题，但只能进行比较测试。除非我错过了什么。

[Sergey Dzyublik]

Alain Verleyen:
如帖子#26674 所示，ArrayResize()没有问题，但只有对比测试有问题。除非我错过了什么。

在一个真实的项目中，当寻找vector<T>::push_back算法的瓶颈时发现了这个问题。
在Release和Debug编译中，该问题作为ArrayResize在保留内存情况下缓慢执行的一部分出现。

你声称一切都很好，因为剖析没有检测到任何东西。
没有人介意获得的结果。
然而，在剖析过程中没有明显的问题，并不能取消在发布和调试编译中的问题，因为100%的用户都会使用这些问题。

[Alain Verleyen]

Sergey Dzyublik :

这个问题是在实际项目中发现的，当时正在寻找vector<T>::push_back算法的瓶颈。
在Release和Debug编译中，该问题作为ArrayResize在保留内存情况下缓慢执行的一部分出现。

你声称一切都很好，因为剖析没有检测到任何东西。
没有人介意获得的结果。
然而，在剖析过程中没有明显的问题，并不能取消在发布和调试编译中的问题，因为100%的用户都会使用这些问题。

我只能谈一谈你提供的测试代码。

在任何情况下，让我们看看开发者有什么要说的。也许。