OOP için genel gider
Ne ek yükünden bahsediyorsun?
Makine kodundan bahsediyorsak - o zaman, bildiğim kadarıyla, sanal bir işlevde - bir sanal işlevler tablosu aracılığıyla dolaylı bir prosedür çağrısı. Ve sıradan işlevler söz konusu olduğunda - doğrudan arama. Bana göre, çok az ek yük var.
Çok daha önemli olan, genel gider programlamadır - kod yazma ve sürdürme, hataları düzeltme...
Parametresiz fonksiyonlar, parametreli fonksiyonlardan daha hızlıdır.
Parametresiz fonksiyonlar, parametreli fonksiyonlardan daha hızlıdır.
Tabii ki, 2 yıldır montajcı oynuyorum)) Doğru, gömülü işlemciler için, ancak C ++ Afrika'da da C ++. Parametresiz bir fonksiyonun bile bir giriş ve bir son sözü vardır ve bu da zaman alır.
En hızlısı, elbette, bir işlev için tasarlanmış bir makrodur. Ne yazık ki MQL'de satır içi işlevler yok, ancak makro biraz değiştirilecek
Ne ek yükünden bahsediyorsun?
Makine kodundan bahsediyorsak - o zaman, bildiğim kadarıyla, sanal bir işlevde - bir sanal işlevler tablosu aracılığıyla dolaylı bir prosedür çağrısı. Ve sıradan işlevler söz konusu olduğunda - doğrudan arama. Benim düşünceme göre, çok az ek yük var.
Çok daha önemli olan, genel gider programlamadır - kod yazma ve sürdürme, hataları düzeltme...
Tabii ki, çalışma zamanı ek yükü bizi fazladan kilobaytlarla rahatsız etmiyor. Test yap..
Makro elbette en hızlısı olacaktır.
Rinat, MT'de ciddi bir inliner'ın işe yaradığını ve iyi sonuçlar verdiğini söyledi.
Evet, MT4'teki kişisel gözlemlere göre, inliner'ın çalışması yığının boyutuna (yığındaki değişkenler için ayrılan bellek) ve değişkenlerin sayısına bağlıdır.
Ve MT5'te, yığın boyutuna olan bağımlılığın kaldırıldığı ve optimize edicinin genel olarak orada daha güçlü olduğu görülüyordu.
Kaynak yoğun bir görevle bağlantılı olarak, soru ortaya çıktı - OOP kullanımı geleneksel prosedürel programlamaya kıyasla ne tür bir ek yük sağlıyor.
Benzer testler yaptıran var mı?
Aradaki farkla ilgileniyor:
- Parametrelerle fonksiyon çağırma
- Parametresiz fonksiyon çağırma
- Yukarıdaki işlevin işlevselliği ile bir makro çağırma
- Bir işlevi çağırmak - sınıf yöntemi
- Sanal bir işlevi çağırmak
Kullanıma hazır OO kitaplıkları ile OOP, uygulama geliştirme süresini azaltır. Yürütme hızı açısından, sanal bir işlev çağrılırken küçük bir düşüş mümkündür.
tek uyarı, iyi OO kitaplıklarının mevcudiyetidir.
"Standart Kitaplık" güzellik anlayışımı bozuyor ve DLL'ye girmemi ve C++'da sakince kod yazmamı sağlıyor
Rinat, MT'de ciddi bir inliner'ın işe yaradığını ve iyi sonuçlar verdiğini söyledi.
Evet, satır içi çok agresif ve otomatik.
x64 kod iyileştirici de 32-bit sürümün üzerinde bir kesimdir (bu dal tamamen durdurulmuştur ve geliştirilmemiştir). Ayrıca, x64 optimizer çoğu sanal işlevi doğrudan ve satır içi çağrılara genişletebilir. Sonuçta, sanal işlevler genellikle dejenere olur.
Ancak gerçek ek yükün bağlantılar ve dinamik dizinlerin kontrolü ile işlemlerde olduğu yer. Sürekli izlenmeleri gerekir.
Kaynak yoğun bir görevle bağlantılı olarak, soru ortaya çıktı - OOP kullanımı geleneksel prosedürel programlamaya kıyasla ne tür bir ek yük sağlıyor.
Tabii ki, OOP'nin güzelliğini kaynaklarla ve çok fazla hata ayıklama süresiyle ödemek zorundasınız. OOP, yalnızca uygun bir metin sarmalayıcı olarak veya çalışma zamanı ortamını başlatırken minimum kullanımla anlamlıdır ... Özünde, OOP , programcıların çalışma saatlerinin maliyetini artırmak ve daha gelişmiş ekipmanların satın alınmasını teşvik etmek için tamamen Microsoft'tan bir pazarlama işiydi. Üstelik kendileri aptal değiller ve tüm yazılımı C ve assembler ile yazıyorlar.
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Kaynak yoğun bir görevle bağlantılı olarak, soru ortaya çıktı - OOP kullanımı geleneksel prosedürel programlamaya kıyasla ne tür bir ek yük sağlıyor.
Benzer testler yaptıran var mı?
Aradaki farkla ilgileniyor: