Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri - sayfa 102
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
Eh, zaten çok ileri gittin) Önce mesaj kuyruğundan geçer. İkincisi, bazı ek dönüşümler (ileri geri) yapmanız gerekir. Ayrıca bir çeşit doğrulama oluyor.
Bu arada,yapının boyutu açıkça belirtilmemelidir. Sizeof bunun için var.
Belki başka bir koda baktınız.
Sürümümde sevmediğim tek şey tehdit: dizenin sonu olarak sıfır alınır. Omuriliğimle daha kolay bir çözüm olduğunu hissediyorum ama bulamadım. Ama yine de daha hızlı çalışıyor.
SetWindowText/GetWindowText mesajlar yoluyla gönderilemedi mi?
Gidiş dönüş dönüşümü yoktur.
Tabii ki. Ve teflerle ne tür danslar:
SetWindowText/GetWindowText mesajlar yoluyla gönderilemedi mi?
Ve sen Windows mesajları hakkında ... Ne olmuş yani? Kendi kendine yazılan dll'ler olmadan Windows'ta farklı programlar arasında veri alışverişi için daha hızlı bir alternatif var mı?
Sözlerimden incindiğini anlıyorum, versiyonum akıllı. İlk olarak, bunu iddia etmedim, sadece varsaydım. İkincisi, varsayımımı Memory Mapping ile karşılaştırıldığında test koduyla destekledim.
Ve siz, bir varsayımı bile çürütmeye çalışıyorsanız, lütfen çürütmenizi yalnızca beyan edici ifadeler üzerine inşa etmeyin. Beni vazgeçirirseniz ve kendi kendine yazılmış dll'ler olmadan terminaller arasında daha hızlı bir veri alışverişi uygulamasına işaret ederseniz size çok minnettar olacağım.
RAM diski üzerinden seçeneğin çok daha hızlı olacağını ekarte etmiyorum. Ancak bu biraz farklı bir konudur, çünkü bu RAM diskinin yüklenmesini ve yapılandırmasını gerektirir.
Tabii ki. Ve teflerle ne tür danslar:
Onlar da benim için tef buldular. Bu banallik. Ve bu arada, bu önemsizlik, kene yapısını elde etmek için tüm blok 90 μs'de (90.000 ns) tamamlandığında 50-60 ns'de tamamlanır, yani bu "elmaslar" zamanın yalnızca %0.06'sını alır. veri bloğu. Ayrıca, bu anın sadece hafızamın iki katına çıkması nedeniyle kafamı karıştırdığını yazdım .
Ve bu yüzden benim sürümüm, küçük veri yapılarını değiştirmek için çok kullanışlı, basit ve akıllı görünüyor.
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Kitaplıklar: GeçmişTicks
Otomatik Ticaret , 2018.03.29 11:09
Vay!
CryptEncode ve CryptDecode gibi işlevleri bile bilmiyordum. Teşekkür ederim!
Çalışacağım.
PS Ancak şimdiye kadar, ilk bakışta, bunların hepsi, elbette, yüksek teknoloji, ancak delice yavaş, çünkü CryptEncode işlevi, burada tef olarak adlandırılandan iki büyüklük sırası daha yavaş (mikrosaniyeye karşı onlarca nanosaniye) yürütülür:
Sözlerimden incindiğini anlıyorum, versiyonum akıllı. İlk olarak, bunu iddia etmedim, sadece varsaydım. İkincisi, varsayımımı Memory Mapping ile karşılaştırıldığında test koduyla destekledim.
Evet, "çevik" değilim, ama " mevcut tüm çözümlerden daha hızlı olması mümkündür " hakkında. Bu nedenle, herhangi bir baskın yapmadan birkaç yorum yaptım. Ve bu sözler oldukça haklıydı. Sadece bir nedenden dolayı ilk başta inatla inkar ediyorsunuz ("muhtemelen başka bir koda baktınız" ) ve sonra "ne olmuş!" konumuna geliyorsunuz. Öyleyse yine de sinekleri pirzolalardan ayıralım.
İlk olarak, benim gönderim, test kodunuzu göndermeden önce yazılmıştır. İkincisi, MemoryMapping (veya daha doğrusu, bahsedilen MQL sarmalayıcısı) ile ilgili olarak, hiçbir yerde hızlı çalıştığını iddia etmedim. Ayrıca buradaki bu projenin tartışma başlığında yazarın frenleri oluşturan hatalarına ve bunların nasıl düzeltileceğine dikkat çektim. Bu nedenle, zaten bir şeyi test etmeyi taahhüt ettiyseniz, onu yerel bir biçimde test edin , başkasının yanlış kararları şeklinde değil.
PS Ancak şimdiye kadar, ilk bakışta, bunların hepsi, elbette, yüksek teknoloji, ancak delice yavaş, çünkü CryptEncode işlevi, burada tef olarak adlandırılandan iki büyüklük sırası daha yavaş (mikrosaniyeye karşı onlarca nanosaniye) yürütülür:
Hız ne için?
Evet, "çevik" değilim, ama " mevcut tüm çözümlerden daha hızlı olması mümkündür " hakkında. Bu nedenle, herhangi bir baskın yapmadan birkaç yorum yaptım. Ve bu sözler oldukça haklıydı. Sadece bir nedenden dolayı ilk başta inatla inkar ediyorsunuz ("muhtemelen başka bir koda baktınız" ) ve sonra "ne olmuş!" konumuna geliyorsunuz. Öyleyse yine de sinekleri pirzolalardan ayıralım.
İlk olarak, test kodunuzu göndermeden önce mesajım yazılmıştır. İkincisi, MemoryMapping (veya daha doğrusu, bahsedilen MQL sarmalayıcısı) ile ilgili olarak, hiçbir yerde hızlı çalıştığını iddia etmedim. Ayrıca buradaki bu projenin tartışma başlığında yazarın frenleri oluşturan hatalarına ve bunların nasıl düzeltileceğine dikkat çektim. Bu nedenle, zaten bir şeyi test etmeyi taahhüt ettiyseniz, onu yerel bir biçimde test edin , başkasının yanlış kararları şeklinde değil.
TAMAM. Kabul. Çok yüksek sesle söyledi.
Sadece, WinAPI kullanarak iki terminali birbirine bağlamaya gelince, kernel32.dll yerine user32.dll kullanmanın daha hızlı olabileceğini söylemek istedim. tanıştığım tüm uygulamalar kernel32.dll kullanıyordu.
Hız ne için?
Üzgünüm, soruyu anlamadım.
Soruyorsunuz - terminaller arasındaki köprünün veri değişim oranı için ne gerekiyor?
Üzgünüm, soruyu anlamadım.
Soruyorsunuz - neden terminaller arasındaki köprünün veri değişim oranına ihtiyacımız var?
Evet.
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri
Nikolai Semko , 2018.09.21 13:20
PS Ancak şimdiye kadar, ilk bakışta, bunların hepsi, elbette, yüksek teknoloji, ancak delice yavaş, çünkü CryptEncode işlevi, burada tef olarak adlandırılandan iki büyüklük sırası daha yavaş ( mikrosaniyeye karşı onlarca nanosaniye ) yürütülür: