Parıltı ve sefalet OOP - 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
Gerçek projelerde doğrudan aramanın veya sanal aramanın hiçbir etkisinin olmadığını gösterdi.
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.
Nerede gösterdi? Bazı fonksiyon isimleri ve ölçümleri olan bir tablo - bu bir argüman mı? Biz kesinlikle telepat değiliz. İşlev kodunu görmeniz gerekir, o zaman yine de bir şey hakkında konuşabilirsiniz.
Nerede gösterdi? Bazı fonksiyon isimleri ve ölçümleri olan bir tablo - bu bir argüman mı? Bizler kesinlikle telepat değiliz. İşlev kodunu görmeniz gerekir, o zaman yine de bir şey hakkında konuşabilirsiniz.
Gerçek projelerde doğrudan aramanın veya sanal aramanın hiçbir etkisi olmadığını gösterdi.
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.
+100 Evet, doğru!
Ayrıca, aşırı büyümüş sınıfları, bazı işlevlerinin diğer sınıflar tarafından gerçekleştirileceği (dahil etme / ayrıştırma) şekilde yeniden yazmam gerektiğinde, genel performansın arttığını ve kod üzerindeki kontrolün arttığını fark ettim. Onlar. Uygulamada, Tamsayı ve eski tarz C severlerin bize kanıtlamaya çalıştığı durumun tam tersi bir durum gözlemleniyor: sınıf sayısı artıyor, yöntem sayısı artıyor ve tam tersine performans artıyor.
Nerede gösterdi? Bazı fonksiyon isimleri ve ölçümleri olan bir tablo - bu bir argüman mı? Bizler kesinlikle telepat değiliz. İşlev kodunu görmen gerekiyor, o zaman hala bir şey hakkında konuşabilirsin.
+100 Evet, doğru!
Ayrıca, aşırı büyümüş sınıfları, bazı işlevlerinin diğer sınıflar tarafından gerçekleştirileceği (dahil etme / ayrıştırma) şekilde yeniden yazmam gerektiğinde, genel performansın arttığını ve kod üzerindeki kontrolün arttığını fark ettim. Onlar. Uygulamada, Tamsayı ve eski tarz C severlerin bize kanıtlamaya çalıştığı durumun tam tersi bir durum gözlemleniyor: sınıf sayısı artıyor, yöntem sayısı artıyor ve tam tersine performans artıyor.
Kendi kendine hipnozun yeni bir yolu mu? Hadi, hadi.
Vasily, yine de burada kanıtlamaya çalıştığım şeyi okuyacaksın (ve ne düşünürsen, kanıtladım).
Ancak, kaynak kodlarının varlığının size hiçbir şey vermeyeceğini not ediyorum. Genel karmaşıklık aynı değildir. Kaynak kodlarını analiz ettikten sonra bile, "oha, orada bir şey denir, bir şey düşünülür, bir yerden bir şey alınır, ama tam olarak ne olduğu belli değil, bu yüzden hiçbir şey tekrar kanıtlanmadı" diyebilirsiniz.
Genel olarak, belki evet, haklısınız, bireysel işlevler muhtemelen hiçbir şey hakkında çok az şey söyleyecektir. O zaman, diğer herkes için dürtme yapan bir domuzsa, programınız hakkında bir konuşma başlatmanın anlamı neydi?
Aslında bizi asıl ilgilendiren sanal yöntem geçişlerinin toplam sayısı ve buna harcanan toplam süre. Burada tablonuzda 5 milyon kez yürütülen bazı gölgeli işlevler var. Ne olduğunu bilmiyorum, belki de en basit eylemi olan sanal bir yöntem vardır. Ancak, 5 milyon önemsiz bir rakam. Programda ağır hesapların olmadığına ve bu nedenle tartışılacak bir şey olmadığına inanıyorum. Şimdi, diyelim ki, 30000x30000 doğrusal denklem sistemi hesaplandıysa ve matris öğelerine erişim sanal yöntemlerle gerçekleştirildiyse, o zaman zaten konuşulacak bir şey var.
Kendi kendine hipnozun yeni bir yolu mu? Hadi, hadi.
Vasily, yine de burada kanıtlamaya çalıştığım şeyi okuyacaksın (ve ne düşünürsen, kanıtladım).
Dmitry, ne senden yanayım ne de karşıyım. Anlamak için, derleyici tarafından satır içi oluşturmanın içini ve dışını bilmeniz gerekir, ancak bu bilgiyi MQ için açmak, bir kod çözücünün yazılmasına yardımcı olmakla eşdeğerdir.
Burada sadece Renat'ın böyle bir bilgisi var (tartışanlardan), bu yüzden onun sözüne güvenmek zorunda kalacağız. Başka bir yol görmüyorum.
Testi yanlış yaptığınızı söylüyorsa, görünüşe göre öyle.
Soru farklıdır, bu durumda sadece MQ doğru şekilde test edebilir ve başarılması gereken de budur.
Test için test dedikleri gibi, sözüm sizinkine karşı. Ve kanıtlanamayanı kanıtlamaya çalışıyorsun. Karşılaştırılacak hiçbir şey olmadan ifadelerinizi kanıtlamak veya çürütmek imkansızdır.
Decompiler burada söz konusu değil.
Vahşice optimize edilmiş ve doğrusal koda dönüşen basitleştirilmiş dejenere durumları test etmemek için derleyicileri optimize etme tekniklerini anlamanız ve bilmeniz yeterlidir. Boşuna chtoli, dördüncü nesil derleyicileri yayınladık.
İşte tam da bununla ilgili.
Şimdi, diyelim ki, 30000x30000 doğrusal denklem sistemi hesaplandıysa ve matris öğelerine erişim sanal yöntemlerle gerçekleştirildiyse, o zaman zaten konuşulacak bir şey var.
Bu gibi durumlarda, ilk yeniden düzenleme, hızlanmada yüz kat artış sağlayacaktır. Ayrıca, sanal bir arama, maliyetler açısından onuncu sırada yer alacaktır.
Yani, örnek gerçekçi değil.
O zaman her şeyi assembler'da yazalım. Her iki şekilde de daha hızlı olacaktır.
Ben sorunun özünü anlamıyorum. HİÇ 1 MB kodlu bir Uzman Danışman veya gösterge görmedim.
Herhangi bir işlevin çağrılması da biraz zaman alır. Fonksiyonlardan kurtulalım!
OOP ile büyük projeler üzerinde kontrol çok daha uygundur.
Ek olarak, kod yürütme hızı çoğu zaman aracıya ping süresi ve aracının siparişe verdiği yanıt kadar kritik değildir.
HFT algoritmalarına bakın. Maksimum performans gerektirirler, ancak orada karmaşık hesaplamalar bulamazsınız.
not. A Noktasından B Noktasına gitmek için, kural olarak, bir süper arabaya veya bir BELAZ kariyerine ihtiyacınız yoktur. Yeter moped!