MT5 Kod Profil Oluşturucu Hakkında - sayfa 3
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Devamında:
Satırlardan hangisi (1, 2 veya 3) hala kaynak yoğun?
Tüm programın zamanının %55'ini alan "ağır" iTime'ın nasıl sadece %0,81 Self CPU gösterdiğini anlayamıyorum?
Ve tam tersi - neden açılış braketi (1) ve en basit koşul (2, çok nadiren doğrudur) %33,84 Self CPU gösteriyor?
Self CPU ve Total CPU neden uyumlu değil?
İşlev gerçekten ağırdır, ancak tüm ağırlığı kodun daha aşağısında bulunur. Ve profil oluşturucu, iTime ve iki boole değişkeni için bir yedek aramayı mı önerir?!
Ben açıkçası bir şey anlamıyorum.
Ben açıkçası bir şey anlamıyorum.
Kayabilir mi?
Kayabilir mi?
Rapordaki aynı rakamlara benzemiyor.
İlyas, çözmeme yardım et.
1. Neden boş bir işlevi çağırmak Self CPU'nun %34.5'ini kaplayabilir? Aynı zamanda, iç kısımları Toplam CPU'nun %38,16'sı tarafından yürütülen onu takip eden fonksiyonun çağrısı raporda hiç görüntülenmiyor mu?
İşlev kodu:
2. Aynı örnek ikinci sorunu gösteriyor: TimeCurrent() içeren satır, yalnızca işlev içinde değil, genel olarak program içinde de makul olmayan bir şekilde uzun zaman alıyor:
CheckTimeSeries() gövdesini yorumlamadan önce, yükün büyük kısmı TimeCurrent() satırındaydı.
İşlev gerçekten bu kadar ağır mı? Onu ne ile değiştirmeli? Veya nasıl ekonomik hale getirilebilir (bir program yürütme döngüsü içinde önbelleğe alma)?
Mümkün olan her yerde ekonomik hesaplamalar yapıyorum, hesaplamaları inceltiyorum (bar başına bir, X saniyede bir, Y ms'de bir vb.). Ancak, hesaplama yapmanın gerekli olup olmadığı kontrolün kendisinin çok kaynak yoğun olduğu ortaya çıktı.
Yardımın için teşekkürler.
1) kod olmadan, belki de optimizasyon nedeniyle bu tür istatistiklerin neden olduğunu söylemek zor
2) Timer fonksiyonunda neden döngüden önce zamanı alıp parametre olarak iletmeye çalışmıyorsunuz, bu fonksiyonu döngüde en az 2 * N kez çağırmanın anlamı nedir?
Devamında:
Satırlardan hangisi (1, 2 veya 3) hala kaynak yoğun?
Tüm programın zamanının %55'ini alan "ağır" iTime'ın nasıl sadece %0,81 Self CPU gösterdiğini anlayamıyorum?
Ve tam tersi - neden açılış braketi (1) ve en basit koşul (2, çok nadiren doğrudur) %33,84 Self CPU gösteriyor?
Self CPU ve Total CPU neden uyumlu değil?
İşlev gerçekten ağırdır, ancak tüm ağırlığı kodun daha aşağısında bulunur. Ve profil oluşturucu, iTime ve iki boole değişkeni için bir yedek aramayı mı önerir?!
Ben açıkçası bir şey anlamıyorum.
1) Fonksiyonun satır içi olduğunu varsayacağım
2) Sayaçlar gerçekten bağlı değil, SelfCPU - yukarıdaki kodda çağrılan fonksiyonları hesaba katmadan fonksiyon kodundaki yük, bu bir IF operatörüdür (dal)
3) TotalCPU sayacı, bu program dalındaki tüm çağrılar için yürütme dalının yükünü gösterir.
Her zaman %100 olması gerekmez mi? Veya @global_initializations ve @global_deinitializations da göz önüne alındığında biraz daha az.
%102'den fazla var ...(Geçmiş verilere göre 3003 oluşturun).
1) Fonksiyonun satır içi olduğunu varsayacağım
2) Sayaçlar gerçekten bağlı değil, SelfCPU - yukarıdaki kodda çağrılan fonksiyonları hesaba katmadan fonksiyon kodundaki yük, bu bir IF operatörüdür (dal)
3) TotalCPU sayacı, bu program dalındaki tüm çağrılar için yürütme dalının yükünü gösterir.
Nasıl faydalıdır? Açıkçası, IF ifadesinin kendisi düşük CPU kullanımına sahiptir. İşlev çağrılarını içermesi gerekmez mi?
Neyse. Nasıl anlaşılır (Andrey'in örneğinden):
if(!simulated) taking 3.86% ?!?
Peki buna ne dersin???
Görünen o ki aynı Tick() fonksiyonundayız!
Profiler'ı gerçekten kullanmak ve anlamak istiyorum ama hiçbir anlamı yok. Pişmanlık.
Ne yapalım ? Nasıl yardımcı olabiliriz?
1) kod olmadan, belki de optimizasyon nedeniyle bu tür istatistiklerin neden olduğunu söylemek zor
2) Timer fonksiyonunda neden döngüden önce zamanı alıp parametre olarak iletmeye çalışmıyorsunuz, bu fonksiyonu döngüde en az 2 * N kez çağırmanın anlamı nedir?
Cevaplar için teşekkürler!
1) Basit bir kod üzerinde yeniden oluşturmam pek mümkün değil, evet. Ve tüm proje vermeye hazır değil.
2) Bu özel durumda, katılıyorum.
Ancak aynı veya benzer denetimi kullanan başka birçok sınıf vardır ve TimeCurrent veya GetTickCount vazgeçilmezdir.
Aynı değeri birkaç kez istememek için çağrılarını nasıl optimize edebilirim?
Ve TimeCurrent gerçekten çok ağır hesaplamaların (her 1 veya 5 dakikada bir yapılmasına rağmen) arka planında fark edilebilecek kadar ağır mı?
Yoksa yine yanlış mı anladım ve Toplam CPU'nun %38.16'sı / Self CPU'nun %26.07'si if kontrolünün kendisi tarafından mı işgal edildi ( TimeCurrent işlevine yapılan çağrı hariç)? Ama o zaman bu neden böyle?
1) Fonksiyonun satır içi olduğunu varsayacağım
2) Sayaçlar gerçekten bağlı değil, SelfCPU - yukarıdaki kodda çağrılan fonksiyonları hesaba katmadan fonksiyon kodundaki yük, bu bir IF operatörüdür (dal)
3) TotalCPU sayacı, bu program dalındaki tüm çağrılar için yürütme dalının yükünü gösterir.
1) Bu kadar açgözlü bir açma braketinin neden anlaşılmasına yardımcı olmaz. Nasıl yorumlanır?
2) SelfCPU hakkında artık açık, teşekkürler. Bu, çağrılan işlevleri hesaba katmadan işlev kodundaki bir yüktür.
Bu aynı zamanda iTime ile hattın düşük SelfCPU'sunu da açıklıyor - çok nadiren ulaşıldı, nadiren çağrıldı.
Ama neden bu kadar büyük bir TotalCPU var? Yoksa tüm programdaki tüm iTime'ın (ve diğer CopyXXX işlevlerinin) yükünü gösteriyor mu?
Cevaplar için teşekkürler!
1) Basit kodda yeniden oluşturmam pek mümkün değil, evet. Ve tüm proje vermeye hazır değil.
2) Bu özel durumda, katılıyorum.
Ancak aynı veya benzer denetimi kullanan başka birçok sınıf vardır ve TimeCurrent veya GetTickCount vazgeçilmezdir.
Aynı değeri birden çok kez istememek için çağrılarını nasıl optimize edebilirim?
Ve TimeCurrent gerçekten çok ağır hesaplamaların (her 1 veya 5 dakikada bir yapılmasına rağmen) arka planında fark edilebilecek kadar ağır mı?
Yoksa yine yanlış mı anladım ve Toplam CPU'nun %38.16'sı / Self CPU'nun %26.07'si if kontrolünün kendisi tarafından mı işgal edildi ( TimeCurrent işlevine yapılan çağrı hariç)? Ama o zaman bu neden böyle?
1) Bu kadar açgözlü bir açma braketinin neden anlaşılmasına yardımcı olmaz. Nasıl yorumlanır?
2) SelfCPU hakkında artık açık, teşekkürler. Bu, çağrılan işlevleri hesaba katmadan işlev kodundaki bir yüktür.
Bu aynı zamanda iTime ile hattın düşük SelfCPU'sunu da açıklıyor - çok nadiren ulaşıldı, nadiren çağrıldı.
Ama neden bu kadar büyük bir TotalCPU var? Yoksa tüm programdaki tüm iTime'ın (ve diğer CopyXXX işlevlerinin) yükünü gösteriyor mu?
Standart dağıtımdan herhangi bir kod alın, profilini çıkarın ve ona göre sorular sorun, lütfen. Bu, durumu tekrarlanabilir bir şekilde değerlendirmenize ve doğru cevaplar vermenize olanak tanır.
Aksi takdirde, profil oluşturucu raporlarından kodunuzun küçük parçalarının sorumlu olması iyi değildir. Tüm kodunuzu tamamen farklı bir karışık ve satır içi temsile dönüştüren devasa bir optimize edici işi var.
Bilgi için: Tanrı korusun 100 C++ programcısından 1'i profil oluşturucuyu nasıl kullanacağını biliyor ve raporlarını anlıyor. Yerel kod iyileştiriciyi suçlayın.
Neyse. Nasıl anlaşılır (Andrey'in örneğinden):
if(!simulated) taking 3.86% ?!?
Evet, harici işlevlerin çağrısını dikkate almadan SelfCPU çok bilgilendirici değildir. Sadece yerel MQL fonksiyonlarının kullanıldığı en düşük seviyede gerçek yükü görmek mümkün olacaktır.
Ancak aynı zamanda bu işlevlerin hangi yerlerden daha sık çağrıldığı (ve daha fazla tükettiği) ve hangi tekil çağrıların yapıldığı belli olmayacak! Peki, CopyXXX ve OrderXXX işlevlerinin en çok zaman aldığını bilmemin ne anlamı var? Programımın hangi bölümlerinden çok sık/verimsiz olarak çağrıldıklarını bilmem gerekiyor.
Muhtemelen bu mod için
TotalCPU ile birlikte. Çalışacağım. Ama orada gördüğüm kadarıyla tamamen yorumlanmış satırlar (!).