Aynı eyleme neden olan koşullarda birçok "veya" (||)'dan kaçmak mümkün müdür? - sayfa 6
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
borilunad , herhangi bir işlev çağrısı ekstra frenler ekler. Bu nedenle, maksimum hız gerekiyorsa, tek kelimelik işlemler yapan herhangi bir İstek () 'den kurtulmanız gerekir. Aynı şey döngüler için de geçerli. Bir döngüdeki koşulların test edilmesi, yalnızca bir dizi iç içe if() işlevinden her zaman önemli ölçüde daha yavaştır.
Dolayısıyla, birbirini dışlayan koşullar bile if(A || B || C || D) Action ile daha iyidir;
Ama işlev çağrılarından kaçınamam, çünkü Bu noktada, bu koşullara dahil olan birçok veriyi kontrol etmek gereklidir.
Denemeye devam edeceğim, belki bir şeyler kazabilirim. Ama yayılma üzerinde kontrol yok! :)
Ancak, else result= false satırını ilk satırla birleştirmek daha iyidir, pratikte hızı etkilemeyecektir. Ve genel olarak, eğer A, B, C ve D basit koşullar içeriyorsa (minimum aritmetik işlemlerle, herhangi bir matematiksel fonksiyon çağırmadan ve diğer zil ve ıslıklarla), o zaman bu tür optimizasyondan çok fazla performans kazancı elde edemezsiniz. Tabii ki, bu yapı on milyonlarca kez değil sizin tarafınızdan yürütülür). Ancak kod karmaşası önemli olabilir.
Bunu dallardan birinde zaten yazdım, her şeye rasyonel olarak yaklaşılmalıdır. Bazı nedenlerden dolayı, kodunuzda optimizasyonu gerçekten çok büyük bir performans kazancı sağlayacak çok daha önemli yerleriniz var gibi görünüyor. Ana algoritma ile başlamanız gerekir. Yeni başlayanların çoğu, TS veya açık siparişlerle ilgili tüm koşulların her onayında aptalca bir kontrole sahiptir. Bu nedenle frenler. Çoğu durumda, yalnızca sınır koşullarını kontrol etmek yeterli olsa da, örneğin, yüksek ve düşük belirli bir değere ulaşır veya yeni bir çubuğun görünümü. Ve ancak bundan sonra başka kontroller yapın.
Ayrıca, yoğun kaynak gerektiren hesaplamalar söz konusu olduğunda, bu hesaplamaları bir DLL dosyasına aktarmayı düşünmeniz gerekir. Aksi takdirde, lanet olası MQL4'te 13 dakika oturup beklemek (aynı sonucu 2-3 dakika içinde almanıza rağmen) bir şekilde kusurlu :)
Genel olarak, en hızlı seçenek şöyle olacaktır:
Ancak, else result= false satırını ilk satırla birleştirmek daha iyidir, pratikte hızı etkilemeyecektir. Ve genel olarak, eğer A, B, C ve D basit koşullar içeriyorsa (minimum aritmetik işlemlerle, herhangi bir matematiksel fonksiyon çağırmadan ve diğer zil ve ıslıklarla), o zaman bu tür optimizasyondan çok fazla performans kazancı elde edemezsiniz. Tabii ki, bu yapı on milyonlarca kez değil sizin tarafınızdan yürütülür). Ancak kod karmaşası önemli olabilir.
Bunu dallardan birinde zaten yazdım, her şeye rasyonel olarak yaklaşılmalıdır. Bazı nedenlerden dolayı, kodunuzda optimizasyonu gerçekten çok büyük bir performans kazancı sağlayacak çok daha önemli yerleriniz var gibi görünüyor. Ana algoritma ile başlamanız gerekir. Yeni başlayanların çoğu, TS veya açık siparişlerle ilgili tüm koşulların her onayında aptalca bir kontrole sahiptir. Bu nedenle frenler. Çoğu durumda, yalnızca sınır koşullarını kontrol etmek yeterli olsa da, örneğin, yüksek ve düşük belirli bir değere ulaşır veya yeni bir çubuğun görünümü. Ve ancak bundan sonra başka kontroller yapın.
Ayrıca, yoğun kaynak gerektiren hesaplamalar söz konusu olduğunda, bu hesaplamaları bir DLL dosyasına aktarmayı düşünmeniz gerekir. Aksi takdirde, lanet olası MQL4'te 13 dakika oturup beklemek (aynı sonucu 2-3 dakika içinde almanıza rağmen) bir şekilde kusurlu :)
Paco tarafından sunulan en hızlı seçenek
Her seferinde birkaç değeri toplamanın (yani gereksiz aritmetik işlemler gerçekleştirmenin) daha hızlı olduğunu cidden düşünüyor musunuz? Benim versiyonumda, kontrol ilk eşleşmede ve bahsettiğiniz versiyonda sona eriyor - sadece tüm değerleri topladıktan ve ardından toplamı kontrol ettikten sonra.
Ayrıca, bu seçenek TÜM koşulların önceden hesaplanmasını gerektirir. Peki nasıl bir hızdan bahsedebiliriz. Bu en yavaş seçenektir.
hızlandırmaya ihtiyacınız varsa, bitsel işlemleri deneyebilirsiniz.
Onlar. int türündeki tüm değişkenleri yapın (false=0). Sonra parça parça A|B|C...>0
hızlandırmaya ihtiyacınız varsa, bitsel işlemleri deneyebilirsiniz.
Onlar. int türündeki tüm değişkenleri yapın (false=0). Sonra parça parça A|B|C...>0
Ve hiç kimse yürütme hızı için önerilen seçenekleri kontrol etmeyecek mi?
Senaryoyu buradan alabilirsin
Genel olarak, en hızlı seçenek şöyle olacaktır:
Ancak, else result= false satırını ilk satırla birleştirmek daha iyidir, pratikte hızı etkilemeyecektir. Ve genel olarak, eğer A, B, C ve D basit koşullar içeriyorsa (minimum aritmetik işlemlerle, herhangi bir matematiksel fonksiyon çağırmadan ve diğer zil ve ıslıklarla), o zaman bu tür optimizasyondan çok fazla performans kazancı elde edemezsiniz. Tabii ki, bu yapı on milyonlarca kez değil sizin tarafınızdan yürütülür). Ancak kod karmaşası önemli olabilir.
Bunu dallardan birinde zaten yazdım, her şeye rasyonel olarak yaklaşılmalıdır. Bazı nedenlerden dolayı, kodunuzda optimizasyonu gerçekten çok büyük bir performans kazancı sağlayacak çok daha önemli yerleriniz var gibi görünüyor. Ana algoritma ile başlamanız gerekir. Yeni başlayanların çoğu, TS veya açık siparişlerle ilgili tüm koşulların her onayında aptalca bir kontrole sahiptir. Bu nedenle frenler. Çoğu durumda, yalnızca sınır koşullarını kontrol etmek yeterli olsa da, örneğin, yüksek ve düşük belirli bir değere ulaşır veya yeni bir çubuğun görünümü. Ve ancak bundan sonra başka kontroller yapın.
Ayrıca, yoğun kaynak gerektiren hesaplamalar söz konusu olduğunda, bu hesaplamaları bir DLL dosyasına aktarmayı düşünmeniz gerekir. Aksi takdirde, lanet olası MQL4'te 13 dakika oturup beklemek (aynı sonucu 2-3 dakika içinde almanıza rağmen) bir şekilde kusurlu :)
Yani daha da hızlı.
Hikayeyi hatırladım:
"Şirketin yönetim kurulu toplantısında 2 soru vardı:
1. Bir senkrofazotron inşa etme kararı.
2. Çalışanlar için bisiklet rafı yapma kararı.
İlk soruda tartışma 1 dakika sürdü,
2. tartışma 2 saatten fazla sürdü.