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

Yeni yorum
 
fxsaber :

If, else, while, for, kelimelerinin hemen ardından TAB tuşuna basarsanız, küçük bir ek olacaktır. bina...


köknar ağaçları .. sınıfı, mql ile 5 yıl tanıdıktan sonra - öğrendim.

 

SD'deki konuşmadan çıkan bir konuda sonuçlar.

Bir dize değişkenine değer atamanın ÇOK pahalı bir işlem olduğu ortaya çıktı.

O kadar pahalı ki, geliştiriciler derleyicide bu noktayı iyileştirene kadar mümkünse bundan kaçınmak arzu edilir ve bu yakında olmayacak gibi görünüyor.


Örnek olarak, 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.


Kod tabanında, aynı ticaret mantığının farklı uygulamalarında bu tür arızaları tespit etmenize olanak tanıyan küçük bir araç vardır. Hızlı kod yazın.

 
fxsaber :

SD'deki konuşmadan çıkan bir konuda sonuçlar.

Bir dize değişkenine değer atamanın ÇOK pahalı bir işlem olduğu ortaya çıktı.

O kadar pahalı ki, geliştiriciler derleyicide bu noktayı iyileştirene kadar mümkünse bundan kaçınmak arzu edilir ve bu yakında olmayacak gibi görünüyor.


Örnek olarak, 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, o zaman 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 ataması ek neden olabilir. optimize ederken saatlerce beklemek. Dikkatli olun ve bu nüansı göz önünde bulundurun.


Kod tabanında, aynı ticaret mantığının farklı uygulamalarında bu tür arızaları tespit etmenize olanak tanıyan küçük bir araç vardır. Hızlı kod yazın.

Teşekkürler, bunun mümkün olduğunu düşünmemiştim. Gelecekteki gelişmelerde dikkate alacağım

 

Gece için basit bir bilmece, neden sarı sonuçlar?

 struct INT
{
   int Array[];
  
  INT()
  {
     Print ( __FUNCTION__ ); // до сюда не дойдет
  }
};

void OnStart ()
{
  INT i = { 0 };
  
   Print ( ArrayResize (i.Array, 5 )); // -1
}
 
fxsaber :

Gece için basit bir bilmece, neden sarı sonuçlar?

Yapı kurucuyla değil sıfırlarla dolu olduğundan, bu nedenle dizi yapısı yanlış başlatılır, arrayresize bu tür dizileri sevmez, kodum genellikle böyle bir yeniden boyutlandırmada çöktü.
 
birleştirici :
Yapı kurucuyla değil sıfırlarla dolu olduğundan, bu nedenle dizi yapısı yanlış başlatılır, arrayresize bu tür dizileri sevmez, kodum genellikle böyle bir yeniden boyutlandırmada çöktü.

Herkesin bunu bilmesi güzel.

 
Slava :

GetMicrosecondCount anlamına gelir. Sunucuyu yavaşlatıp yavaşlatmadığını kesin olarak söylemek mümkün değil. Dolaylı bir etkisi olabilir. Bu nedenle, sistem yerel GetTickCount'u kullanmak daha iyidir.

GetMicrosecondCount, kod yürütmenin kısa bölümlerini ölçmek için kullanılır. Büyük bir OnTicks setinin yürütülmesini ölçmek için GetTickCount yine de daha iyidir

Kararlı sonuçlar aldıktan sonra GetTickCount yerine GetMicrosecondsCount kullanmayı deneyin. O zaman buradan söyle. Belki boşuna endişeleniyorum

Hipotezinizin doğru olduğu ortaya çıktı, GetMicrosecondsCount'a yapılan çoklu çağrı, test cihazında korkunç frenlere neden oluyor. Ancak GetTickCount aynı etkiye sahiptir.
 
fxsaber :

SD'deki bir konu ile ilgili görüşmeden çıkan sonuçlar .

Bir dize değişkenine değer atamanın ÇOK pahalı bir işlem olduğu ortaya çıktı.

O kadar pahalı ki, geliştiriciler derleyicide bu noktayı iyileştirene kadar mümkünse bundan kaçınmak arzu edilir ve bu yakında olmayacak gibi görünüyor.


Örnek olarak, 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, o zaman 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 ataması ek neden olabilir. optimize ederken saatlerce beklemek. Dikkatli olun ve bu nüansı göz önünde bulundurun.


Kod tabanında, aynı ticaret mantığının farklı uygulamalarında bu tür arızaları tespit etmenize olanak tanıyan küçük bir araç vardır. Hızlı kod yazın.

 struct STRUCT
{
   string Str;
  
   string Get() const { return ( this .Str); }
};

void OnStart ()
{
  STRUCT Struct;
  
   Print (Struct.Str);
   Print (Struct.Get()); // Выполняется гораздо дольше, чем предыдущая строка
}
 
fxsaber :

Bir dize değişkenine değer atamanın ÇOK pahalı bir işlem olduğu ortaya çıktı.

...

karşılaştırmadan önce, işlevin sonucunu bir dizge değişkenine atar ve ardından karşılaştırırsanız, çalıştırma süresi yaklaşık bir saniye artacaktır.

Anladığım kadarıyla, sorun atamanın yüksek maliyetinde değil, derleyicinin bir nedenden dolayı bu ekstra atamayı, olması gerektiği halde koddan kesmemesidir. Onlar. derlenen kod her iki durumda da aynı olmalıdır.
 
Alexey Navoykov :
Anladığım kadarıyla, sorun atamanın yüksek maliyetinde değil, derleyicinin bir nedenden dolayı bu ekstra atamayı olması gerektiği halde koddan kesmemesidir. Onlar. derlenen kod her iki durumda da aynı olmalıdır.

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.

Derleyici tarafından optimize edilemeyen bir kod yazın, ancak içinde bir atama yapın. Ve frenleri görün.

Ve bir yapının dize alanını bir fonksiyon aracılığıyla okuma örneği , konum özelliklerinin okunmasının MT4/5'te tam olarak nasıl uygulandığıdır.

MT4'te, aynı OrderSymbol(), MT5'te uygulanmışsa bir frendir. Geliştiricilerin kendileri, dizeleri bağlantılar aracılığıyla işlevlerine geçirmeye çalışırlar.

Yani böyle bir şey yazarsan

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

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


Genel olarak, TesterBench'i kullanmaya başladığımda birdenbire net bir yavaşlama gördüm.

1...424344454647484950515253545556...247
Yeni yorum