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
Sevgili geliştiriciler, MQL_MEMORY_USED'in nasıl hesaplandığını bize anlatır mısınız?
Tüm EA değişkenlerinin kapladığı belleği hesapladım.
Bu %10'dan az. Doğru anlarsam, MQL_MEMORY_USED, Geçmiş önbelleğini ve CopyTicks önbelleğini içerir. Ama yine de çok daha az sürmelidir.
Aynı zamanda, paralel danışman birkaç kat daha az yer. Prensip aynı olmasına rağmen.
Genel olarak, bu değere neler dahildir?
Not: Şablonu danışmanla birlikte kaydettim ve aynı grafiğe uygulayarak yeniden başlatmaya neden oldum. Öyle oldu.
Bellek tüketimi neredeyse büyüklük sırasına göre değişti. Bunun ne anlama geldiğini açıklamak zor.
Bellek kullanımının kümülatif etkisi birçok programdadır. Tarayıcılar bununla günah işler, aynı Word, bazen yapabilir. Terminal de günah işler. Ek olarak, herkes varsayılan günlükler yazar ve çok fazla eylem varsa, o zaman bir haftada bir konserde uçup gitmek kolaydır. Bu, kontrol edilmesi gereken bir kötülüktür. Gerçek nasıl belli değil.
Belki bir finansal enstrümanı programlı olarak nasıl seçeceğinizi ve yüzyıllarca takılıp kalmayacağınızı biliyorsunuzdur?
gösterge aracılığıyla
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
MT5 ve iş başında hız
Renat Fatkhullin , 2020.10.14 04:15
Kenelerle toplu çalışma için daha fazla bellek ayarlayın.
Analitik ve araştırma söz konusu olduğunda 4 GB (fiyatı 20 Euro) 2020'de iyi değil.
Market ürünleri için bu yaklaşım iyi değildir. Böyle bir koltuk değneği ile gereksiz verilerin 10 saniyelik bellekte tutulmasını atlamanız gerekir.
Önemsiz bir Market ürününü Market Screener şeklinde yapmak, aşırı bellek tüketimi nedeniyle aslında MT5 için uygun bir görev değildir.
Önemsiz bir Market ürününü Market Screener şeklinde yapmak, aşırı bellek tüketimi nedeniyle aslında MT5 için uygun bir görev değildir.
Terminal, başlatıldıktan sonra çok fazla bellek tüketiyor.
Screener'ın çalıştırılmasından sonra 2 gigabayt yemeye başladı (TERMINAL_MEMORY_USED ve zamanla azalmadı). Bu, 5000 M1-çubuk için yalnızca bir açık grafikle.
Ekran görüntüsü kaydedilmedi. Ancak, Terminal'in aptalca olduğu yerde kendi belleğini tükettiğini gösteren bir örnek atmaya karar verdim.
Komut dosyası, Market Watch'tan orijinal sembollerin kopyalarını çıkarır. MQ-Demo'daki tüm sembolleri eklemem ve bu betiği ilk kez soğuk bir senaryoda ve ardından tekrar sıcak bir senaryoda çalıştırmam gerekiyordu.
Ve sıcak (keneler zaten SSD'de tkc dosyaları biçimindeyken) başlatıldıktan sonra, uygun uygulama ile hiç gerekli olmayan yerlerde vahşi bellek tüketimini gözlemleyeceğim.
Ancak scripti çalıştırırken MQ-Demo'da asılı kaldığı gerçeğiyle karşılaştım. Yalnızca Anormal sonlandırma yoluyla kaldırılır, bundan sonra Terminal 1 GB'den fazla bellek serbest bırakmaz.
Bu ekranı başlangıçtaki ekranla karşılaştırmak kolaydır.
Üzgünüz, bunun bir hata mı yoksa bir özellik mi olduğundan emin değilim. Cevabı kendim bulamadım. Ancak soru performansla ilgili ve bence bu soruyu burada sormak daha iyi.
Örneğin, boş bir göstergeye DRAW_SECTION türünde 22 arabellek eklenirse, böyle bir gösterge 1.000.000 çubuk veya daha fazla olan bir grafikte başlatıldığında, terminal oldukça yavaşlamaya başlar (ayrıca üzerinde gözle görülür bir yük vardır). CPU) ve gösterge hiçbir şey hesaplamasa bile gözle görülür miktarda RAM tüketin.
Benim ilgi alanım, diğer türlerle arabellek kullanırsanız, her şeyin sorunsuz çalışması ve böyle bir yavaşlama olmamasıydı.
Örneğin, aşağıdaki gösterge kodunu 1.000.000 çubuk içeren tek bir grafikte çalıştırdım ve terminal yaklaşık 500 MB yedi ve özellikle grafiğin kendisi olmak üzere gözle görülür şekilde gecikti.
Ancak arabellek türünü örneğin DRAW_LINE olarak değiştirirseniz, işlemci üzerindeki yük keskin bir şekilde düşer, gecikme olmaz ve RAM 5 kat daha az tüketilir (yaklaşık 100 MB tüketilir).
2019 yapılarına kadar farklı yapılar üzerinde benzer testler yaptım ve durum aynı.
Bireysel bir vatandaş aldı geniş pantolonlardan Aynı koşullar altında koltuk değneğinin standart işlevden daha hızlı çalıştığını gösteren paha biçilmez kargo MQL kodunun bir kopyası .
Çok basit test:
EURUSD'de 20 Uzman Danışman, yani. tüm OnTick'ler aynı anda işlenebilir. Terminal derleme 2664. Testi optimizasyon, derleme vb. olmadan çalıştırın. %100 işlemcide ekstra yükleme - böyle bir arka plana karşı gerçek bir "hft" ticareti yapmayacaksınız, değil mi?
Tipik test günlüğü:
Çok basit test:
EURUSD'de 20 Uzman Danışman, yani. tüm OnTick'ler aynı anda işlenebilir. Terminal derleme 2664. Testi optimizasyon, derleme vb. olmadan çalıştırın. %100 işlemcide ekstra yükleme - böyle bir arka plana karşı gerçek bir "hft" ticareti yapmayacaksınız, değil mi?
Tipik test günlüğü:
Aynı tik üzerinde 1,5 saniye içerisinde 100K iterasyon yaparak sera koşulları yaratırsınız. Özellikle OnTick oluşturmayan keneleri bekledim.
Alım satım günlüklerime baktığımda, SymbolInfoTick'in birkaç milisaniye içinde yürütüldüğünü fark ettim. Aynı zamanda, o anda tam bir Boşta CPU olduğunu %100 biliyorum.
Her şey çok basit. Koşullu olarak günde 1 milyon kene. %0,01 tiklerde bile frenler - gecikmeli günde 100 tik. Bunun saçmalık olduğunu söyleyeceksin. Kötüyüm. Sipariş vermem gerektiğinde gecikme yaşarsam, bu potansiyel bir para kaybıdır.
Bu konunun gözden kaçmadığı için çok minnettarım ve özellikle bu özellik üzerinde hızlandırmak için çok çalışma yapılmıştır. Ancak, bazı durumlarda korkunç bir koltuk değneğinin normal işlevi geride bırakabilmesi benim için biraz beklenmedik bir şeydi. Ve belki de, bu birikimi çözer ve ortadan kaldırırsanız, o zaman günde 100 potansiyel gecikme 10'a dönüşür.
Şube başlangıcından çok daha iyi hale geldiğini söylüyorum. Ama gerçek şu ki - iyi olmadığı anlar var. Ve bunu anlamak istemediğinizi görüyorum. Seçiminize saygı duyuyorum.
Yukarıda güncel fiyatları almak için anlık görüntü seçeneği verdim. Boşta-CPU makinesinde milisaniyelik gecikmeler yakalamasaydı bana tamamen uyuyordu.
Ayrıca SymbolInfoTick'in sadece hızından değil, aynı zamanda verdiği fiyatların uygunluğundan da endişe duyuyorum. Bu konuyu gündeme getirmediğinizi görüyorum. Görünüşe göre, daha sonra bakmaya karar verdiler.
Aynı tik üzerinde 1,5 saniye içerisinde 100K iterasyon yaparak sera koşulları yaratırsınız. Özellikle OnTick oluşturmayan keneleri bekledim.
Alım satım günlüklerime baktığımda, SymbolInfoTick'in birkaç milisaniye içinde yürütüldüğünü fark ettim. Aynı zamanda, o anda tam bir Boşta CPU olduğunu %100 biliyorum.Her şey çok basit. Koşullu olarak günde 1 milyon kene. %0,01 tiklerde bile frenler - gecikmeli günde 100 tik. Bunun saçmalık olduğunu söyleyeceksin. Kötüyüm. Sipariş vermem gerektiğinde gecikme yaşarsam, bunlar potansiyel parasal kayıplardır.
Bu konunun gözden kaçmadığı için çok minnettarım ve özellikle bu özellik üzerinde hızlandırmak için çok çalışma yapılmıştır. Ancak, bazı durumlarda korkunç bir koltuk değneğinin normal işlevi geride bırakabilmesi benim için biraz beklenmedik bir şeydi. Ve belki de, bu birikimi çözüp ortadan kaldırırsanız, o zaman günde 100 potansiyel gecikme 10'a dönüşecektir.
Şube başlangıcından çok daha iyi hale geldiğini söylüyorum. Ama gerçek şu ki - iyi olmadığı anlar var. Ve bunu anlamak istemediğinizi görüyorum. Seçiminize saygı duyuyorum.
Yukarıda güncel fiyatları almak için anlık görüntü seçeneği verdim. Idle-CPU makinesinde milisaniyelik gecikmeleri yakalamasaydı bana çok yakışırdı.
Ayrıca SymbolInfoTick'in yalnızca hızıyla değil, aynı zamanda verdiği fiyatların uygunluğuyla da ilgileniyorum. Bu konuyu gündeme getirmediğinizi görüyorum. Görünüşe göre, daha sonra bakmaya karar verdiler.
Bunlar hiç de sıcak koşullar değil. Sleep() ve benzeri olmadan ve aynı anda 20 iş parçacığında 100.000 fiyat talebi için bir döngü, bariz bir stres testidir. Gerçek koşullarda böyle bir şey yakın bile olmamalıdır.
Diğer kenelerin 1,5 saniyede gelmediğini düşünüyorsanız - tamam, 10 milyon istekte bulunun, bu hiçbir şeyi değiştirmez, "koltuk değneğiniz" daha kötü çalışır:Bu ifadeniz %100 yanlıştır:
Daha önceki açıklamanız gibi:
SymbolInfoTick aracılığıyla fiyatlara erişim artık çok hızlıdır ve tik akışı işlemeden tamamen ayrılmıştır. Çok ekonomik ve hızlı bir şekilde güncellenen hazır fiyat önbelleği ile çalışıyorsunuz.
Tüm "tiklerin %0,01'inde frenler" yalnızca stres testi koşulları altında görünür ve bu mükemmel bir sonuçtur. Normal koşullar altında, erişimin çok hızlı olması garanti edilir.
SymbolInfoTick'i "hızlandırmak için çok çalışma yapıldığını" kabul ediyorsanız, o zaman bana, PositionSelectByTicket üzerinden fiyat almanın "koltuk değneğinin" en iyi çözüm olmayabileceğine inanmalısınız.
Basit bir nedenden dolayı - PositionSelectByTicket'in uygulanması, SymbolInfoTick'in orijinal "yavaş" uygulanmasıyla tamamen aynıdır.
Yukarıda yazdığım gibi, bu uygulama kelimenin tam anlamıyla yavaş değildir, ancak yoğun CPU yükü altında, daha yüksek çalışma zamanı ani yükselme olasılığına sahiptir (ki bu, son testimde açıkça görülmektedir).
Burada, zamanlamalar yüksek oranda sistem görev zamanlayıcısının yük altındaki çalışmasına bağlıdır, yani. farklı işletim sistemlerinde ve hatta sürümlerinde farklılıklar olabilir.
Yük ne kadar büyükse, terminalin değil görev zamanlayıcının verimliliğini o kadar çok test edersiniz.
SymbolInfoTick'in bu performansı konusunu kapatıyorum.
Uzmanlarınız sentetik stres testleri düzeyinde bir yük oluşturuyorsa, o zaman tek bir çözüm var: "Donanım görevlere uygun olmalı."
SymbolInfoTick tarafından sağlanan kenelerin alaka düzeyi hakkında bir sorum var.
Durum:
1. TimeCurretn() yapın; 18:00:00 saatini al
2. Kötü tanımlanmış bir sembol üzerinde SymbolInfoTick yapıyoruz. Saat 17:58:00 olan bir tik alıyoruz.
3.Uyku(1)
4. Kötü tanımlanmış bir sembol üzerinde SymbolInfoTick yapmak. Saat 17:59:00 ile bir onay işareti alıyoruz.
Yani dördüncü paragrafta, TimeCurretn()'den bir dakika farklı olan yeni bir onay işareti aldık.
Bu durumda bir sorun görüyor musunuz?
Böyle bir duruma daha az nasıl girilir?
SymbolInfoTick tarafından sağlanan kenelerin alaka düzeyi hakkında bir sorum var.
Durum:
1. TimeCurretn() yapın; 18:00:00 saatini al
2. Kötü tanımlanmış bir sembol üzerinde SymbolInfoTick yapmak. Saat 17:58:00 olan bir tik alıyoruz.
3.Uyku(1)
4. Kötü tanımlanmış bir sembol üzerinde SymbolInfoTick yapmak. Saat 17:59:00 ile bir onay işareti alıyoruz.
Yani dördüncü paragrafta, TimeCurretn()'den bir dakika farklı olan yeni bir onay işareti aldık.
Bu durumda bir sorun görüyor musunuz?
Böyle bir duruma daha az nasıl girilir?
SymbolInfoTick , aracının sunucusundan alınan verileri döndürür. Sunucunun gönderdiği şey, aldığınız şeydir.
Aracı kurumunuzun yayınladığı onay akışı hakkında sorularınız varsa, aracı kurumunuza başvurmalısınız.