Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri - sayfa 50

Yeni yorum
 
fxsaber :

Bu küçük bir sorun. Evet, derleyici iyileştirici henüz bu tür dize anlarını optimize edemiyor. Ancak yavaşlama sorunu dizi atamasındadır.

Ve bence bu her şeyden önemlidir. Hangi etkiden daha fazlası olacak: atamayı hızlandırmaktan mı yoksa onu koddan çıkarmaktan mı? Evet, elbette bu atamanın tek başına gerekli olduğu durumlar var ama bu ne sıklıkla oluyor? Vakaların büyük çoğunluğunda, yalnızca geçici değişkenlerle ilgileniriz.

Ve bu string işlemlerini ne kadar hızlandırabileceğiniz de bir sorudur. Zaman zaman hızlandırılabilirmiş gibi tartışıyorsunuz. Ben şüpheliyim. Zaten orada tekrar tekrar her şey optimize edildi-yeniden optimize edildi. Pekala,% 20-30 daha sıkmak mümkün olsun - bu hava durumu yapmaz.

Bu arada, bir dize değişkenini sabit olarak bildirmeyi denediniz mi?

Yani böyle bir şey yazarsan

 if (( OrderSymbol () == Symb) && ( OrderMagicNumber == Magic))

Genel koşulun sonunda OrderSymbol koşulunu zorlamak her zaman daha iyidir.

Pekala, söylemeye gerek yok. Ve OrderSymbol'un bununla hiçbir ilgisi yok, tıpkı MQL gibi. Dize işlemleri başlı başına pahalıdır, bu nedenle bunları boşuna kullanmamalısınız.

 

Peki, arada

fxsaber :

örneğin, FIBO'da ayda gerçek tiklerle bir koşu yaparsanız, yaklaşık 1 milyon tik olacaktır. Her tikte PositionGetString değerini alır ve bir şeyle karşılaştırırsanız, performans kabul edilebilir olacaktır, ancak karşılaştırmadan önce işlevin sonucunu bir dize değişkenine atar ve ardından karşılaştırırsanız, çalıştırmanın süresi yaklaşık bir saniye artacaktır.


Bu önemsiz gibi görünüyorsa, bu hatalı bir vizyondur. Böyle bir danışman birkaç bin geçiş için optimizasyon modunda başlatıldığında, bu eklenir. ikinci ekstra ile sonuçlanır. bekleme saatleri. Onlar. zararsız dizi atama ek neden olabilir. optimize ederken saatlerce beklemek. Dikkatli olun ve bu nüansı göz önünde bulundurun.

Umarım bu yaklaşımın son derece verimsiz olduğunu anlıyorsunuzdur. Neden her onayda PositionGetString olsun? Orada ne değişebilir? Özellikle bu pozisyonu sizin açtığınız düşünülürse, yani. her şey önceden biliniyor.

Genel olarak, performansı optimize etmekten bahsediyorsak, öncelikle programın mantığını optimize etmeniz gerekir.

 
Alexey Navoykov :

Ve bu string işlemlerini ne kadar hızlandırabileceğiniz de bir sorudur. Zaman zaman hızlandırılabilirmiş gibi tartışıyorsunuz. Ben şüpheliyim. Zaten orada tekrar tekrar her şey optimize edildi-yeniden optimize edildi. Pekala,% 20-30 daha sıkmak mümkün olsun - bu hava durumu yapmaz.

faktörü.

Bu arada, bir dize değişkenini sabit olarak bildirmeyi denediniz mi?

Sınanmış.
 
Alexey Navoykov :

Neden her onayda PositionGetString olsun? Orada ne değişebilir? Özellikle bu pozisyonu sizin açtığınız düşünülürse, yani. her şey önceden biliniyor.

Genel olarak, performansı optimize etmekten bahsediyorsak, öncelikle programın mantığını optimize etmeniz gerekir.

Böyle bir mantığa sahip bir savaş robotu - böyle bir zaman aralığında EURUSD'de açık pozisyon olmamalıdır. Varsa kapatın.

Açık bir GBPUSD pozisyonunuz var. Her tikte OrderSymbol'u kontrol etmeden yukarıdaki koşul nasıl yerine getirilir?

Ya da özel yazmayı teklif edersiniz. danışmanın özellikle testçi için sürümü? İşte bir savaş robotu satın alan ve onu test eden bir adam. Markete her şeyin test cihazı için hız için özel olarak optimize edildiğini yazın?

 
fxsaber :

Böyle bir mantığa sahip bir savaş robotu - böyle bir zaman aralığında EURUSD'de açık pozisyon olmamalıdır. Varsa kapatın.

Açık bir GBPUSD pozisyonunuz var. Her tikte OrderSymbol'u kontrol etmeden yukarıdaki koşul nasıl yerine getirilir?

Ya da özel yazmayı teklif edersiniz. danışmanın özellikle testçi için sürümü? İşte bir savaş robotu satın alan ve onu test eden bir adam. Markete her şeyin test cihazı için hız için özel olarak optimize edildiğini yazın?

Eh, sadece mevcut açık pozisyonların biletlerini kontrol etmek yeterlidir (ve buna göre bir dizi tutmak). Yeni bir bilet belirdiyse, diğer tüm kontrolleri gerçekleştirin. Neden aynı şeyi milyonlarca kez kontrol ediyorsun?

Bu arada, MQL5'te ticaret olayları var. Bu nedenle her keneyi kontrol etmeye gerek yoktur.

 
Alexey Navoykov :

Eh, sadece mevcut açık pozisyonların biletlerini kontrol etmek yeterlidir (ve buna göre bir dizi tutmak).

Çok daha ucuz olmayacak.

Ve bu arada, MQL5'te ticaret olayları var. Bu nedenle, her bir onay işaretini kontrol etmeye hiç gerek yoktur.

Bazen platformlar arası çözümler yazıyorlar. Ayrıca, tüm ticaret olaylarını alma garantisi yoktur ve olamaz.

 
fxsaber :

Çok daha ucuz olmayacak.

Tamsayı işlemleri arasındaki fark, dize işlemlerinden çok daha ucuz değil mi? Peki, nasıl istersen.

 
Alexey Navoykov :

Tamsayı işlemleri arasındaki fark, dize işlemlerinden çok daha ucuz değil mi? Peki, nasıl istersen.

Buna neden ihtiyacın olduğunu anlamadım ama beni yedin. Ve bir dizi bilet içeren seçeneğin daha üretken olacağına katılıyorum.

Doğru, bazı mantık açısından, bu seçenek çok yapay görünüyor, programın mantıksal yapısına değil, teknik bir nüansa zaten dayanıyor.

Ama yine de alacağım. Tabii ki kod tabanında hiç böyle bir yaklaşım görmedim.

 

MQL'de çoklu kalıtımın olmaması elbette iç karartıcı. Ancak, doğaçlama yollarla çıkabilirsiniz: şablonlar ve makrolar - onlarsız)

İşte yığılmış bir seçenek. Tüm kaynak sınıflar, üst sınıfı tanımlayan şablonlar olarak bildirilmelidir.

 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);
}

Elbette, sınıfların paralel olarak değil (gerçek çoklu kalıtımda olduğu gibi) sıralı olarak (belirlediğimiz sırayla) miras alınması nedeniyle burada nüanslar vardır. Özellikle, bir aşırı yük meydana geldiğinde farklı önceliklere sahip olacaklardır. Ayrıca, aynı şablon sınıfı birkaç kez kalıtım zincirine katılırsa, bunlar birbiriyle hiçbir şekilde ilişkili olmayan tamamen farklı sınıflar olacaktır. Bu yüzden burada dikkatli olmalısınız. Ancak arayüzlerde sorun yok, kısıtlama olmadan devralabilirsiniz.

 
Alexey Navoykov :

MQL'de çoklu kalıtımın olmaması elbette iç karartıcı. Ancak, doğaçlama yollarla çıkabilirsiniz: şablonlar ve makrolar - onlarsız)

İşte yığılmış bir seçenek. Tüm kaynak sınıflar, üst sınıfı tanımlayan şablonlar olarak bildirilmelidir.

Elbette, sınıfların paralel olarak değil (gerçek çoklu kalıtımda olduğu gibi) sıralı olarak (belirlediğimiz sırayla) miras alınması nedeniyle burada nüanslar vardır. Özellikle, bir aşırı yük meydana geldiğinde farklı önceliklere sahip olacaklardır. Ayrıca, aynı şablon sınıfı birkaç kez kalıtım zincirine katılırsa, bunlar birbiriyle hiçbir şekilde ilişkili olmayan tamamen farklı sınıflar olacaktır. Bu yüzden burada dikkatli olmalısınız. Ancak arayüzlerde sorun yok, kısıtlama olmadan devralabilirsiniz.

Hoş geldiniz. İşin püf noktası , şablonu TParent'e uygulamaktır . Daha önce böyle bir şey görmemiştim.

1...434445464748495051525354555657...247
Yeni yorum
Neden: