Doğrusal yavaşlama - bir programcının hatası mı yoksa MT4'ün bir özelliği mi? - sayfa 11
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
MetaQuotes takma adı altında bu şeyi kimin paylaştığını gerçekten bilmek istiyorum, kişisel bir mesajla cevap verebilir miyim?
Koda göz attım. Hemen aklıma Lermontov'un şiirinden bir alıntı geldi:
Şimdi sorunuz hakkında:
-Aleks- :
Stratejiyi ve özellikle taktikleri sonuçlandırma aşamasında, fikri test etmek için her türlü eklemeyi sipariş etmeniz gerekiyor, bu aşamada danışmanın yavaşlığına katlanmak oldukça mümkün.
Ancak, danışmanın ana versiyonuna kıyasla 6 kat daha hızlı bir düşüşe şaşırdım. EA ayarlarının optimizasyonu, en azından analitik verilerin toplanması için gereklidir.
Başka birinin kodunu okumanın imkansız olduğunu ve danışmanın başarılı bir sürümünü kendiniz onayladıktan sonra tekrar sipariş etmenin daha iyi olduğunu doğru anlıyorum, ancak sıfırdan ne yazılır ve yalnızca bu durumda yüksek hızdan emin olabilirsiniz. ve güvenilirlik? Şahsen, derleyicinin görevinin bir kısmı, örneğin birbirini kopyalayan işlemleri kesmek gibi geldi ...
Bu koddan bahsetmiyorum, genel olarak global. Onlar. bu ifadeyi reddediyor musunuz?"Atlar bir grup halinde karışık, insanlar" tarzında yazan programcılar sipariş ederseniz - o zaman sürekli artan bir bütçe için iki veya üç kez değil, genel olarak sürekli ve her zaman% 100 yeniden yazmanız gerekir. Profesyonellerden sipariş verirseniz, gereksinimleri %20, %40, hatta %80 oranında değiştirmek, kodun yalnızca tamamen değil, hatta değişikliklerin yüzdesiyle aynı oranda yeniden yazılmasını gerektirmez. Ama "<50$" bir bütçeyle, unut gitsin.
Açık emirlere emir gönderirken yapay bir gecikme yapmanın gerekli olduğunu doğru anladım, ancak aynı zamanda açıldıklarına dair onay beklememek mi?
Elbette, EA bir sipariş gönderirken tüm hataları işlemelidir. En basit versiyonda - bir siparişin başarısız açılması hakkında bir mesaj görüntüleyin. Daha gelişmiş olarak - daha fazla eyleme karar vermek için.
Bu yüzden beni değiştirecek bir danışmana ihtiyacım var, burada daha fazla eylem çok alakalı ... ancak zamanında olacakları gerçeği değil (örneğin, fiyat zaten hesaplanan giriş noktasından çok uzağa gitti).
Göndermedim. Kodlayıcıdan doğrulama için IsTradeContextBusy kullanmasını isteyin.
Tavsiyeniz için teşekkürler, ancak bir sonraki dalda bahsettiğim şey bu nüanslar hakkındaydı. Bunu nasıl bilebilirim?
509 yapı kullanıyorsanız, 8 iş parçacığı vardır. IsTradeContextBusy ile durum teoride ortaya çıkmamalıdır.
Varsa, yukarıdaki paragrafa bakın.
birden fazla terminal de kullanabilirsiniz.
Burada anlamadım, terminal sayısı bir siparişin geçişini etkiler mi? Onlar. Aynı hesapta birkaç terminal çalıştırabilir ve her birinden bir emir açmak için emir gönderebilirsiniz ve eğer bunların yarısı boğulursa, diğer yarısı emri başarıyla yerine getirir mi? Siparişin DC tarafından işlenmesi gerektiğini düşündüm ve ancak bundan sonra bir sonrakini kabul et ...
Koda göz attım. Hemen aklıma Lermontov'un şiirinden bir alıntı geldi:
Şimdi sorunuz hakkında:
"Atlar bir grup halinde karışık, insanlar" tarzında yazan programcılar sipariş ederseniz - o zaman sürekli artan bir bütçe için iki veya üç kez değil, genel olarak sürekli ve her zaman% 100 yeniden yazmanız gerekir. Profesyonellerden sipariş verirseniz, gereksinimleri %20, %40, hatta %80 oranında değiştirmek, kodun yalnızca tamamen değil, hatta değişikliklerin yüzdesiyle aynı oranda yeniden yazılmasını gerektirmez. Ama "<50$" bütçeyle, unut gitsin.
Şimdi danışman bana 100 dolardan fazlaya mal oluyor ve buna eklemeye devam edeceğimi biliyorum. Bu matematik ortaya çıkıyor:
Her biri 30$'lık 10 revizyon 300$, 50$'lık 10 revizyon ise 500$ veriyor. Ancak her şey bana uygun olduğunda, sıfırdan bir danışman sipariş edebilirim (fazlalığı atarak) ve 80 dolara mal olacak, sonuç olarak, bu yaklaşım, özellikle geliştirme devam ederken kendini haklı çıkarır. Bu sadece sinirlerin yıpranması gerekiyor ... ama sonra ne kadar şanslı.
Yanlış anlaşıldı. Yapay gecikmeler olmamalıdır. MT5, uyku() gecikmeleri yerine kullanılması gereken basit bir olay modeline sahiptir.
Tavsiyeniz için teşekkürler, ancak bir sonraki dalda bahsettiğim şey bu nüanslar hakkındaydı. Bunu nasıl bilebilirim?
ve onlara bakıp bir şey aramanıza gerek yok.
Birisi nasıl olması gerektiğini ima ettiyse ve kodda böyle bir kodun bulunmadığını bulduysanız - kodlayıcıyı sessizce değiştirin. Şube oluşturmayın.
Burada anlamadım, terminal sayısı bir siparişin geçişini etkiler mi? Onlar. Aynı hesapta birkaç terminal çalıştırabilir ve her birinden bir emir açmak için emir gönderebilirsiniz ve eğer bunların yarısı boğulursa, diğer yarısı emri başarıyla yerine getirir mi?
kaç terminal - bu ve gönderilecek akışların çokluğu. 10 terminal 1 sipariş gönderecek - 10 sipariş olacak.
Bu yüzden beni değiştirecek bir danışmana ihtiyacım var, burada daha fazla eylem çok alakalı ... ancak zamanında olacakları gerçeği değil (örneğin, fiyat zaten hesaplanan giriş noktasından çok uzağa gitti).
Şimdi danışman bana 100 dolardan fazlaya mal oluyor ve buna eklemeye devam edeceğimi biliyorum. Bu matematik ortaya çıkıyor:Her biri 30$'lık 10 revizyon 300$, 50$'lık 10 revizyon ise 500$ veriyor. Ancak her şey bana uygun olduğunda, sıfırdan bir danışman sipariş edebilirim (fazlalığı atarak) ve 80 dolara mal olacak, sonuç olarak, bu yaklaşım, özellikle geliştirme devam ederken kendini haklı çıkarır. Bu sadece sinirlerin yıpranması gerekiyor ... ama sonra ne kadar şanslı.
Bu sizin açınızdan yanlış bir yaklaşımdır.
Optimizasyon hızının önemi konusunda uyaran bir testçi için kod sipariş eder ve gerekli iyileştirmeleri yaparsınız. Ve test sürümü hazır olduktan sonra, gerçek sürümü önceden işlenmiş mantık ve tüm iyileştirmeler/ihtiyaçlar ile sipariş edersiniz.
Çok daha fazla tasarruf olacak. Değil?
ve onlara bakıp bir şey aramanıza gerek yok.
Birisi nasıl olması gerektiğini ima ettiyse ve kodda böyle bir kodun bulunmadığını bulduysanız - kodlayıcıyı sessizce değiştirin. Şube oluşturmayın.
kaç terminal - bu ve gönderilecek akışların çokluğu. 10 terminal 1 sipariş gönderecek - 10 sipariş olacak.
Peki ya DC? Sonuçta, siparişin yapıştırılması tam olarak onunla gerçekleşir!? O zaman bir sürü sipariş göndermenin anlamı ne?
Bu sizin açınızdan yanlış bir yaklaşımdır.
Optimizasyon hızının önemi konusunda uyaran bir testçi için kod sipariş eder ve gerekli iyileştirmeleri yaparsınız. Ve test sürümü hazır olduktan sonra, gerçek sürümü önceden işlenmiş mantık ve tüm iyileştirmeler/ihtiyaçlar ile sipariş edersiniz.
Çok daha fazla tasarruf olacak. Değil?
Pekala, başlangıçta test hızının, test cihazının veya gerçek olanın uygulanmasına çok bağlı olduğunu varsaymadığım gerçeğiyle başlayacağım.
Ve geri kalanı ile ilgili olarak, ben bunu böyle yapıyorum, test ediyorum, rafine ediyorum ... veya hemen "Ben gerçek değil, test için" yazarsam fiyatın çok daha az olacağını mı söylemek istiyorsunuz? "?
Peki ya DC? Sonuçta, siparişin yapıştırılması tam olarak onunla gerçekleşir!? O zaman bir sürü sipariş göndermenin anlamı ne?
hayır, peki, aynı anda yalnızca bir düzine dolum hızına ihtiyacınız yoksa ısrar etmiyorum.
bir terminalden birer birer gönderebilir, içeriğin yayınlanmasını bekleyebilirsiniz, vb.
Bütün bir düzine birkaç dakika arar ve gidersin.
hayır, peki, aynı anda yalnızca bir düzine dolum hızına ihtiyacınız yoksa ısrar etmiyorum.
bir terminalden birer birer gönderebilir, içeriğin yayınlanmasını bekleyebilirsiniz, vb.
Bütün bir düzine birkaç dakika arar ve gidersin.
Bu yüzden soruyorum, çünkü siparişlerin DC'de nasıl işlendiğini hiç bilmiyorum - paralel mi yoksa sıralı olarak mı?
paralel mi seri mi
İstekler sırayla gelir. ancak Satın Alma işleminin bir sonraki satıştan daha hızlı tamamlanacağı bir gerçek değildir, çünkü bazen bir likidite sağlayıcısı da vardır.
ama dünya algısını basitleştirmek için - her zaman bunun tutarlı olduğunu düşünün.
bu bilgi ne için? konudan sapmayın.