错误、漏洞、问题 - 页 1952

新评论
 
Stanislav Korotky:

编译器在这里没有帮助--经过测试--本地对象通过返回被复制，然后被钉死。在这种情况下，不存在最佳的行动。


你是否进行了速度测试？或者只是诊断对象的创建？如果是第二种情况，那么当然不会从代码中删除任何东西，因为你自己用你的检查来防止这个。

 
Alexey Navoykov:


你是否进行了速度测试？还是你只是在诊断对象创建 的事实？如果是后者，当然不会有什么东西从代码中被剪掉，因为你自己通过你的检查来防止它。

怎么说呢？我所有的检查只包括在构造函数和析构函数中设置的痕迹。如果额外的副本被创建和删除，这对我来说就足以证明没有优化。

 
Alexey Navoykov:


你是否进行了速度测量测试？或者只是诊断对象创建 的事实？如果是第二种情况，那么当然就不会有什么东西从代码中被剪掉，因为你自己用你的检查来防止这种情况。

好吧，如果你不能移动线，你就不能移动更复杂的物体。

 
Stanislav Korotky:

怎么说呢？我所有的检查只包括在构造函数和析构函数中设置的痕迹。如果额外的副本被创建和删除，对我来说，这足以证明缺乏优化。

优化器不能把包含你的跟踪的片段扯出来)。只有那些不影响你的逻辑的东西才能被剪掉。
 

现在在OnTesterInit中，你可以为每个输入参数设置优化范围。然后，测试人员自己生成一个通过表，将其分割成Agent/Package的数量，并将其发送给Agent。这个表现在不能以任何方式进行编辑。

但在优化过程中，首先关注的是一些重要参数的变化，然后是另一个参数的变化，等等，这实际上是非常常见的。如果有可能编辑生成的通行证表格（改变元素的位置（输入参数集））或自己生成它，就有可能设置必要的优先级，当最有趣的通行证将首先进入代理公司，然后是不太有趣的通行证。


因此，我建议在OnTesterInit中增加改变默认通过表的可能性。

long PassesTotal(); // количество проходов в таблице для Оптимизации

// Получает список входных параметров соответствующего прохода
int PassesGet( const int Index,  MqlParam& Parameters[] );


// Прописывает список входных параметров для соответствующего прохода,
// если индекс не меньше размера таблицы, то идет дозапись в конец таблицы и размер ее увеличивается на единицу
int PassesSet( const int Index, const MqlParam& Parameters[] );
 
Alexey Navoykov:
优化器将无法切割带有你的轨迹的部分 )唯一可以剪掉的是不干扰你的逻辑的东西。

好了，这个话题已经结束了;-)。我认为这种情况下的优化只可能发生在返回值 出现的那个代码地方，而绝不取决于构造函数中的内容。

C++11标准：当满足某些条件时，允许实现省略类对象的复制/移动构造，即使该对象的复制/移动构造器和/或析构器有副作用。在这种情况下，实现将被省略的复制/移动操作的源和目标视为对同一对象的两种不同的引用方式，并且该对象的销毁发生在没有优化的情况下这两个对象被销毁的时间中较晚的一个。

 
Stanislav Korotky:

好了，这个话题已经结束了;-)。在我看来，这种情况下的优化只能发生在发生返回值 的那段代码中，而不取决于构造函数中的内容。

无论如何，我必须遗憾地承认，MQL编译器远没有我想象的那么聪明 )我甚至可以说它一点都不聪明。 ) 我试着做了一些简单的例子，结果发现，即使我创建了一个假的对象，它没有被用到任何地方，也没有做任何事情，编译器也不会在意它。它根本就没有优化。我是单从速度上判断的。而且由于某些原因，它在新的构建中比在旧的构建中工作得更慢。

下面是一个微不足道的代码。

class A { };

void OnStart()
  {
    uint starttick= GetTickCount();
    for (int i=0; i<1 e8; i++)
    { 
      A a;
    }
    Print(GetTickCount()-starttick," ms");
  }
 
Alexey Navoykov:

好吧，我不得不遗憾地承认，MQL编译器并不像我想象的那么聪明 )我甚至会说这根本就不聪明）。


你有没有想过，可以对它进行调整，以优化大多数人使用的真正的东西，而不是你凭空写的那些废话？

 
Stanislav Korotky:

好了，这个话题已经结束了;-)。在我看来，这种情况下的优化只能发生在返回值 的代码中，而决不是取决于构造函数中的内容。


2年后才引入复制构造函数。
RVO（返回值优化）和NRVO（命名返回值优化）是下一步的工作...

 
Sergey Dzyublik:

你有没有考虑过，可能会对大多数人使用的真正的东西进行锐化优化，而不是他们凭空捏造的废话？

什么是 "大多数人使用的真正的东西"？
1...194519461947194819491950195119521953195419551956195719581959...3184
新评论