mql5语言的特点、微妙之处以及技巧 - 页 50 1...434445464748495051525354555657...247 新评论 Alexey Navoykov 2017.07.20 12:08 #491 fxsaber:这是个小问题。是的,编译器优化器还不知道如何优化这种字符串时刻。但是,字符串分配才是放慢速度的问题。我相信它是主要的。哪种方法更有效:更快的字符串赋值或将其从代码中排除?当然,在有些情况下,我们需要字符串赋值本身,但我们有多少次这样的机会?在绝大多数情况下,我们只是在处理临时变量。而这些字符串操作的实现速度如何,也是一个问题。你把它说得好像可以加速许多倍。我怀疑这一点。他们已经对那里的一切进行了多次的优化--过度优化。假设他们设法再挤出20-30%,也不会有什么影响。顺便说一下,你没有尝试将字符串变量声明为常数吗?因此,如果你在写这样的东西。if ((OrderSymbol() == Symb) && (OrderMagicNumber == Magic))最好把OrderSymbol条款放在一般条件的最后。嗯,当然了。而且它与OrderSymbol或MQL没有关系。字符串操作本身就很昂贵,所以你不应该白白地使用它们。 Alexey Navoykov 2017.07.20 12:32 #492 因此在这之间fxsaber:例如,如果我们在FIBO上运行一个月的真实ticks,将是约100万ticks。如果在每一个tick上,你得到PositionGetString的值,并与之进行比较,性能是可以接受的,但如果你先把函数的结果赋给一个字符串变量,然后再进行比较,运行时间会增加一秒钟左右。如果这看起来是一件小事,那是错误的设想。当这样的EA在优化模式下运行几千次时,多出的这一秒就会转化为额外的几个小时的等待时间。也就是说,一个无害的字符串赋值可能会在优化过程中造成额外的时间等待。要小心并考虑到这种细微差别。我希望你自己明白,这种方法是非常低效的。为什么我们要在每个刻度 上获得PositionGetString?它在那里能改变什么?特别是考虑到你自己开设了这个职位,也就是说,一切都已经事先知道了。因此,如果我们谈论的是速度优化,那么我们必须首先优化程序逻辑本身。 fxsaber 2017.07.20 15:55 #493 阿列克谢-纳沃伊科夫。而这些字符串操作的加速速度如何,也是一个问题。你把它说得好像可以加速许多倍。我怀疑这一点。他们已经对那里的一切进行了多次的优化--过度优化。即使你设法多榨出20-30%,也不会有什么不同。有时。顺便说一下,你难道没有尝试过将字符串变量声明为常量吗? 是的,我做到了。 fxsaber 2017.07.20 15:58 #494 阿列克谢-纳沃伊科夫。为什么要在每个刻度 上获取PositionGetString?那里能有什么变化?特别是考虑到你自己开设了这个职位,也就是说,一切都已经提前知道了。好吧,如果我们在谈论优化性能,那么我们必须首先优化程序逻辑本身。一个战斗机器人有这样的逻辑:在这样的时间间隔内,欧元兑美元应该没有开仓。如果有,就关闭它们。你有一个未平仓的英镑兑美元头寸。我们怎样才能在不检查每个tick的情况下满足上述条件?或者你建议为测试者编写一个特殊版本的专家顾问?在这里,一个人买了一个战斗机器人,正在测试它。如何在市场上解释一切以速度为导向的优化? Alexey Navoykov 2017.07.20 16:41 #495 fxsaber: 有这种逻辑的战斗机器人--在这个时间间隔内,欧元兑美元应该没有开仓。如果有,就关闭它们。你有一个未平仓的英镑兑美元头寸。我们怎样才能在不检查每个tick的情况下满足上述条件?或者你建议为测试者编写一个特殊版本的专家顾问?在这里,一个人买了一个战斗机器人,正在测试它。我们是否应该在市场中写明,所有的东西都是为测试人员特别优化的速度?那么,只检查当前开仓 的票据就足够了(从而保持一个数组)。如果有一张新票,那么所有其他检查都必须用它来进行。为什么我们要把同样的东西检查一百万次?顺便说一下,MQL5有贸易活动。因此,没有必要在每次打勾时都检查它。 fxsaber 2017.07.20 16:57 #496 Alexey Navoykov: 那么,只检查当前开仓 的股票就足够了(并相应地维护一个数组)。这将不会便宜很多。顺便说一下,MQL5有贸易活动。因此,没有必要对每一个蜱虫进行检查。有时会写出跨平台的解决方案。此外,不存在也不可能保证获得所有的贸易活动。 Alexey Navoykov 2017.07.20 17:34 #497 fxsaber:这不会便宜很多。整数操作与字符串操作相比,并没有便宜多少?好吧,随你便。 fxsaber 2017.07.20 21:11 #498 阿列克谢-纳沃伊科夫。整数操作与字符串操作相比,并没有便宜多少?好吧,随你便。我不明白你为什么需要它,但你让我很困惑。而且我不得不同意,有一系列门票的选项会更有成效。诚然,从一些逻辑的角度来看,这样的变体看起来非常做作,奠定了技术上的细微差别,而不是程序的逻辑构造。但我还是会考虑到这一点。当然,我在kodobase中从未遇到过这种方法。 Alexey Navoykov 2017.07.21 15:04 #499 当然,MQL中缺乏多重继承是令人沮丧的。然而,你可以用任何可能的方式使它工作--用模板和宏--你将不需要它们 )这是我所做的。所有的源类都应该被声明为定义父类的模板。class CBase { }; // базовый класс // Макросы, задающие список наследования: #define INHERIT1(T) T<CBase> #define INHERIT2(T1, T2) T2<INHERIT1(T1)> #define INHERIT3(T1, T2, T3) T3<INHERIT2(T1,T2)> #define INHERIT4(T1, T2, T3, T4) T4<INHERIT3(T1,T2,T3)> // Различные пользовательские классы: template<typename TParent> class A : public TParent { public: void a() { Print("A"); } }; template<typename TParent> class B : public TParent { public: void b() { Print("B"); } }; template<typename TParent> class C : public TParent { public: void c() { Print("C"); } }; class X : public INHERIT3(A, B, C) { }; // Объявляем класс, наследуемый от A, B, C template<typename T> void SomeFunc(B<T>& obj) { obj.b(); } // Проверочная функция, принимающая класс B void OnInit() { X x; x.a(); x.b(); x.c(); SomeFunc(x); }当然,还有一些微妙之处,与类是按顺序继承的(按照我们设定的顺序),而不是同时继承的(如真正的多重继承)这一事实有关。特别是,当发生过载时,它们会有不同的优先级。此外,如果一个相同的模板类多次参与继承链,它们将是完全不同的类,彼此之间没有任何关系。所以我们在这里必须小心。但是接口没有问题,你可以不受限制地继承。 fxsaber 2017.07.21 21:25 #500 阿列克谢-纳沃伊科夫。当然,MQL中缺乏多重继承是令人沮丧的。然而,你可以用任何可能的方式使它工作--用模板和宏--你将不需要它们 )这是我所做的。所有的源类都应该被声明为定义父类的模板。当然,还有一些微妙之处,与类是按顺序继承的(按照我们设定的顺序),而不是同时继承的(如真正的多重继承)这一事实有关。特别是,当发生过载时,它们会有不同的优先级。此外,如果一个相同的模板类多次参与继承链,它们将是完全不同的类,彼此之间没有任何关系。所以我们在这里必须小心。但在接口方面没有问题,你可以不受限制地继承。这是个好把戏。整个诀窍在于将模式应用 于TParent。我以前没有见过这样的情况。 1...434445464748495051525354555657...247 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
这是个小问题。是的,编译器优化器还不知道如何优化这种字符串时刻。但是,字符串分配才是放慢速度的问题。
我相信它是主要的。哪种方法更有效:更快的字符串赋值或将其从代码中排除?当然,在有些情况下,我们需要字符串赋值本身,但我们有多少次这样的机会?在绝大多数情况下,我们只是在处理临时变量。
而这些字符串操作的实现速度如何,也是一个问题。你把它说得好像可以加速许多倍。我怀疑这一点。他们已经对那里的一切进行了多次的优化--过度优化。假设他们设法再挤出20-30%,也不会有什么影响。
顺便说一下,你没有尝试将字符串变量声明为常数吗?
因此,如果你在写这样的东西。
最好把OrderSymbol条款放在一般条件的最后。
嗯,当然了。而且它与OrderSymbol或MQL没有关系。字符串操作本身就很昂贵,所以你不应该白白地使用它们。
因此在这之间
fxsaber:
例如,如果我们在FIBO上运行一个月的真实ticks,将是约100万ticks。如果在每一个tick上,你得到PositionGetString的值,并与之进行比较,性能是可以接受的,但如果你先把函数的结果赋给一个字符串变量,然后再进行比较,运行时间会增加一秒钟左右。
如果这看起来是一件小事,那是错误的设想。当这样的EA在优化模式下运行几千次时,多出的这一秒就会转化为额外的几个小时的等待时间。也就是说,一个无害的字符串赋值可能会在优化过程中造成额外的时间等待。要小心并考虑到这种细微差别。
我希望你自己明白,这种方法是非常低效的。为什么我们要在每个刻度 上获得PositionGetString?它在那里能改变什么?特别是考虑到你自己开设了这个职位,也就是说,一切都已经事先知道了。
因此,如果我们谈论的是速度优化,那么我们必须首先优化程序逻辑本身。
而这些字符串操作的加速速度如何,也是一个问题。你把它说得好像可以加速许多倍。我怀疑这一点。他们已经对那里的一切进行了多次的优化--过度优化。即使你设法多榨出20-30%,也不会有什么不同。
有时。
顺便说一下,你难道没有尝试过将字符串变量声明为常量吗?
为什么要在每个刻度 上获取PositionGetString?那里能有什么变化?特别是考虑到你自己开设了这个职位,也就是说,一切都已经提前知道了。
好吧,如果我们在谈论优化性能,那么我们必须首先优化程序逻辑本身。
一个战斗机器人有这样的逻辑:在这样的时间间隔内,欧元兑美元应该没有开仓。如果有,就关闭它们。
你有一个未平仓的英镑兑美元头寸。我们怎样才能在不检查每个tick的情况下满足上述条件?
或者你建议为测试者编写一个特殊版本的专家顾问?在这里,一个人买了一个战斗机器人,正在测试它。如何在市场上解释一切以速度为导向的优化?
有这种逻辑的战斗机器人--在这个时间间隔内,欧元兑美元应该没有开仓。如果有,就关闭它们。
你有一个未平仓的英镑兑美元头寸。我们怎样才能在不检查每个tick的情况下满足上述条件?
或者你建议为测试者编写一个特殊版本的专家顾问?在这里,一个人买了一个战斗机器人,正在测试它。我们是否应该在市场中写明,所有的东西都是为测试人员特别优化的速度?
那么,只检查当前开仓 的票据就足够了(从而保持一个数组)。如果有一张新票,那么所有其他检查都必须用它来进行。为什么我们要把同样的东西检查一百万次?
顺便说一下,MQL5有贸易活动。因此,没有必要在每次打勾时都检查它。
那么,只检查当前开仓 的股票就足够了(并相应地维护一个数组)。
这将不会便宜很多。
顺便说一下,MQL5有贸易活动。因此,没有必要对每一个蜱虫进行检查。
有时会写出跨平台的解决方案。此外,不存在也不可能保证获得所有的贸易活动。
这不会便宜很多。
整数操作与字符串操作相比,并没有便宜多少?好吧,随你便。
整数操作与字符串操作相比,并没有便宜多少?好吧,随你便。
我不明白你为什么需要它,但你让我很困惑。而且我不得不同意,有一系列门票的选项会更有成效。
诚然,从一些逻辑的角度来看,这样的变体看起来非常做作,奠定了技术上的细微差别,而不是程序的逻辑构造。
但我还是会考虑到这一点。当然,我在kodobase中从未遇到过这种方法。
当然,MQL中缺乏多重继承是令人沮丧的。然而,你可以用任何可能的方式使它工作--用模板和宏--你将不需要它们 )
这是我所做的。所有的源类都应该被声明为定义父类的模板。
当然,还有一些微妙之处,与类是按顺序继承的(按照我们设定的顺序),而不是同时继承的(如真正的多重继承)这一事实有关。特别是,当发生过载时,它们会有不同的优先级。此外,如果一个相同的模板类多次参与继承链,它们将是完全不同的类,彼此之间没有任何关系。所以我们在这里必须小心。但是接口没有问题,你可以不受限制地继承。
当然,MQL中缺乏多重继承是令人沮丧的。然而,你可以用任何可能的方式使它工作--用模板和宏--你将不需要它们 )
这是我所做的。所有的源类都应该被声明为定义父类的模板。
当然,还有一些微妙之处,与类是按顺序继承的(按照我们设定的顺序),而不是同时继承的(如真正的多重继承)这一事实有关。特别是,当发生过载时,它们会有不同的优先级。此外,如果一个相同的模板类多次参与继承链,它们将是完全不同的类,彼此之间没有任何关系。所以我们在这里必须小心。但在接口方面没有问题,你可以不受限制地继承。
这是个好把戏。整个诀窍在于将模式应用 于TParent。我以前没有见过这样的情况。