Parıltı ve sefalet OOP - sayfa 5
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
Burada anladığım kadarıyla indeks ikili arama ile mi belirleniyor?
Hayır, dizideki gibi doğrudan erişim.
__________
Um, belki heyecanlandım, şimdi bunu düşüneceğim.
Genel olarak, hiç kimse türün tüm değeri için bir dizi oluşturmaya ve sürekli erişim elde etmeye zahmet etmez. (anahtar yalnızca integral türlerle çalışır)
Tanımladığınız durumda, bir numaralandırma tanıtmak daha uygundur.
Hayır, dizideki gibi doğrudan erişim.
__________
Um, belki heyecanlandım, şimdi bunu düşüneceğim.
Genel olarak, hiç kimse türün tüm değeri için bir dizi oluşturmaya ve sürekli erişim elde etmeye zahmet etmez. (anahtar yalnızca integral türlerle çalışır)
Tanımladığınız durumda, bir numaralandırma tanıtmak daha uygundur.
Türün tam boyutu için mi? Sen nesin! Bu durumda, bu 16 GB bellek gerektirecektir (bir dizi int için). Ve bütün bunların amacı ne? En büyük ve en küçük değer arasındaki farkı hesaplamak yeterlidir. Ancak bu hala tartışmalı bir seçenek çünkü. büyük değerler için, önce kullanıcıyla programa ne kadar bellek vermeye hazır olduğu konusunda anlaşmanız gerekir. Bu nedenle, bu yalnızca küçük anahtar değerler için uygundur (daha doğrusu, maksimum ve minimum arasındaki küçük bir fark için). Ve böylece sadece ikili arama var.
Ve böylece sadece ikili arama var.
Hayır, gerçekten gerekli değil. Kısacası, bir sayının bir enum ile eşlenmesine ihtiyacınız varsa, bir ikili aramaya ihtiyacınız vardır, enum ile çalışmak ve enum'u bir sayıya eşlemek yeterliyse, o zaman sabittir.
Hafızaya gelince, anlıyorum)) bu yüzden heyecanlandığımı yazdım. Dokunmadan hala uzun.
soru için her zaman bir yer vardır - Neden? Yayılma grafiğini çevrimiçi ve test cihazında karşılaştırın. Test edenin gerçeklikle hiçbir ilgisi yok...
Daha ayrıntılı bir açıklama (kanıt) zaten bir yerde verildi mi?
Burada ifadelerinizi kanıtlarla desteklemek gelenekseldir, aksi takdirde onlara bile bakarlar. ;)
Beyler, anahtar belgelerini tüttürün . İyi bir anahtar, performansı seçim sayısından bağımsız olan anahtarlanmış bir geçiştir. Seçenek 1, 100 veya 1000 - geçiş hızı sabit olacaktır.
soru için her zaman bir yer vardır - Neden ? Yayılma grafiğini çevrimiçi ve test cihazında karşılaştırın. Test edenin gerçeklikle hiçbir ilgisi yok...
Kanıt diğer tarafta olacak. Ya da yine, sadece kelimeler.
Genel olarak, yalnızca gerçekler ilgi çekicidir.
OOP'nin daha yavaş olduğunu zaten bilmeme rağmen, çok özel kolaylıklar sağlıyor.
Söz verdiğim gibi, bir projenin profilini çıkarmanın sonuçlarını yayınlıyorum. (Beni suçlamayın, ancak bazı işlevler gizlenmiştir, çünkü kod genel halk için değildir).
Başlangıç olarak, bunun kaynak verilerin güçlü bir şekilde dönüştürülmesiyle gerçek bir OOP projesi olduğunu söyleyeceğim. İçinde OOP kullanma fikri mutlak hale getirildi. Örneğin, genel değişkenleri, dizileri, sınıfların dışındaki işlevleri hiç kullanmaz - çünkü bunlar yeterince OO değildir. Çalışması için, tüm dönem için yapılan sipariş ve işlemlerin geçmişi gereklidir. 6014 işlemin ve 6599 emrin ayrıştırılması işlem başına yalnızca 3,1 saniye veya 0,25 milisaniye sürer, tüm işlemleri, emirleri ve pozisyonları dağıtmak için yaklaşık 13 MB RAM veya işlem başına ortalama 1 kilobayt gerekir. - Bunun bir OOP uygulaması için çok iyi bir sonuç olduğunu düşünüyorum:
Ancak uygulamayı başlatırken harcanan zamanın yapısına bakalım:
Çoğu zaman AddNewDeal işlevini çağırarak harcandığı görülebilir. Bu bileşik bir işlevdir ve gerçek çalışma RecalcValues (%57)'ye devredilmiştir. Sırasıyla, HistoryOrderGetInteger türünün sistem işlevlerinden oluşur:
Bu işlevlerin çağrı sürelerinin yaklaşık olarak aynı olduğunu unutmayın.
Bunun, tüm işlev işlem hattının sonu olduğuna dikkat edin. Bu hesaplamalara ulaşmadan önce bir düzine daha ara OOP yönteminden geçmek gerekiyor ve bunların bir kısmı da sanal. Ancak yürütme süreleri ihmal edilebilir düzeydedir ve profil oluşturucuda listenin ikinci yarısında yer alırlar.
Uygulama %100 OOP olduğundan, kodun zaman açısından kritik bölümlerini takip etmek benim için çok kolay ve performansı çok verimli bir şekilde iyileştirmenin yeni yollarını bulabiliyorum. Geri kalanının (%43) %80-90 CArray.Resize() çağrıları olduğunu zaten biliyorum. Kodun optimize edilmediği ve dizilerin gerektiğinden daha sık yeniden boyutlandırıldığı birkaç yer vardır. Bu OOP modüllerini kolayca yeniden yazabilir ve performansı %25-30 oranında artırabilirim. OOP olmadan, bunu yapmak daha zor olurdu, çünkü her fonksiyon potansiyel olarak sonsuz sayıda ilişkiye katılır ve böyle bir fonksiyondaki değişikliklerin sonuçlarını hesaplamak çok daha zor hale gelir.
Sonuç olarak, karmaşık bir OOP projesinin bile temel sistem işlevlerinin performans sınırına indirilebileceği ortaya çıktı. Ancak OOP olmadan, böyle bir performansı elde etmek daha zor olacaktır, çünkü er ya da geç bir hata yapacak çok sayıda işlev olacaktır: ya fazladan çağrılar yapacaksınız, ya da optimize edilmemiş muadiller ya da çok karmaşık ve hantal uygulamalar yapacaksınız.
soru için her zaman bir yer vardır - Neden? Yayılma grafiğini çevrimiçi ve test cihazında karşılaştırın. Test edenin gerçeklikle hiçbir ilgisi yok...
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Parıltı ve sefalet OOP
tol64 , 2014.07.07 09:12
Dikkat çekmek için. Yeni bir konu açın ve sorunuzu daha ayrıntılı olarak ele alın. Gerçek hayatta nasıl olduğunu ve test cihazında nasıl olduğunu gösterin. Bu soruna çözümünüzü önerin. Aksi takdirde, her şey "şans ve seçenek yok" olarak kalacaktır. )+++
to dimeon - Bir konu açın, bunun neden imkansız olduğu ve neden gerekli olduğu hakkında birçok argüman öğreneceksiniz.
Söz verdiğim gibi, bir projenin profilini çıkarmanın sonuçlarını yayınlıyorum. (Beni suçlamayın, ancak bazı işlevler gizlenmiştir, çünkü kod genel halk için değildir).
...
Neden hepsi bu? İşlevlerinizin kodlarını vermediniz (bazı yırtık parçalar hariç). Peki ne tartışılmalı? Burada konu, özellikle OOP ve prosedürel programlamanın performansını karşılaştırmakla ilgilidir. Ve gizli işlevlerinizin iddiaya göre bir tür iş gerçekleştirdiği, bir yere bir şey devrettiği, biraz zaman harcadığı ve tüm bunları ustaca yönettiğiniz gerçeği - elbette sizin için son derece mutluyuz, ancak bu bilgilerin ne faydası var biz Kodları görmüyoruz.
Neden hepsi bu? İşlevlerinizin kodlarını vermediniz (bazı yırtık parçalar hariç). Peki ne tartışılacak? Burada konu, özellikle OOP ve prosedürel programlamanın performansını karşılaştırmakla ilgilidir. Ve gizli işlevlerinizin iddiaya göre bir tür iş gerçekleştirdiği, bir yere bir şey devrettiği, biraz zaman harcadığı ve tüm bunları ustaca yönettiğiniz gerçeği - elbette, sizin için son derece mutluyuz, ancak bu bilgilerin ne faydası var biz? Kodları görmüyoruz.
Gerçek projelerde doğrudan aramanın veya sanal aramanın hiçbir etkisi olmadığını gösterdi.
gerçek bir OOP projesinin profilini çıkarma örneğini kullanarak, limitteki performansının sistem fonksiyon çağrılarının performansına eğilimli olduğunu göstereceğim.
Maliyetlerin büyük çoğunluğu, MQL programlarının neredeyse tüm zamanının harcandığı çağrı sistemi işlevlerine harcanmaktadır. Çağrı kurulum maliyetleri, yüke kıyasla ihmal edilebilir düzeydedir.