Olayların akışı. Boşta bir olay nasıl kontrol edilir ve yapılır? (+ karar verildi) - sayfa 3

Yeni yorum
 

Yedelkin :

Benzer şekilde, ChartEvent olayı zaten mql5 programının kuyruğundaysa veya böyle bir olay işleniyorsa, bu tür yeni bir olay kuyruğa alınmaz ".

hm. Gerçekten kötü. Bu teorik olarak, örneğin bir hindi ve bir danışman olayları bağımsız olarak kullanırsa, burada ve orada boşluklar olabileceği anlamına gelir.

O zaman olayı veri aktarmanın güvenilir bir yolu olarak kullanmanın bir anlamı yok.

Pichal.

 
sergeev :

Sorunuz "kuyruğun taşmaması için kullanıcı olaylarının yaklaşık olarak ne sıklıkta gönderilmesi gerektiğidir"

ilk sayfadaki cevabım "OnChartEvent'i arama sıklığı ile".

Yani, bir olay - bir OnChartEvent. Arada ikiden fazla olay olmamalıdır.

Bütün matematik bu.

tekrar ilk sayfayı okuyun. Bir kullanıcı olayı yerine bir terminal olayı işlendiğinde kullanıcı olaylarının birikmesinden nasıl kaçınılacağını gösterdim. Her şey basit.

Yine kibarca :) Sorununu çözdün, ben de farklı bir planla benimkini çözmeye çalışıyorum. Tartışmayı okuduğumda, sorularıma cevap bulamadım. Ana soruma (RAM tüketimi hakkında) hala cevap vermediniz (eğer zaten cevaplamayı üstlendiyseniz).

Açıklarım. "Belirli bir işlevi güncellemek, ancak MQL tarafından zamanlayıcı tarafından önerilenden daha hızlı" göreviyle karşı karşıya değilim. Özellikle sonunda önerilen böyle karmaşık bir şekilde. EA ve kullanıcı olay işleyici işlevinin bulunduğu ayrı bir grafiği bombardıman eden birkaç çizelgeden kullanıcı olaylarım var. Buna göre, dar odaklı görevinizi ( OnChartEvent içindeki EventChartCustom) çözmenin sonucu, özel olaylarla çalışma planıma hiç uymuyor.

 

Yedelkin :

Açıklarım. "Belirli bir işlevi güncellemek, ancak MQL tarafından zamanlayıcı tarafından önerilenden daha hızlı" göreviyle karşı karşıya değilim. Özellikle sonunda önerilen böyle karmaşık bir şekilde. EA ve kullanıcı olay işleyici işlevinin bulunduğu ayrı bir grafiği bombardıman eden birkaç çizelgeden kullanıcı olaylarım var. Buna göre, dar odaklı görevinizi ( OnChartEvent içindeki EventChartCustom) çözmenin sonucu, özel olaylarla çalışma planıma hiç uymuyor.

o sofistike değil, basit. Eğer anlayamıyorsanız, o zaman bu benim baş ağrım değil. bu zaman

OnChartEvent'in içinde değil, kodun her yerine dağılmış durumda. Sen kendin işine dar kısıtlamalar getiriyorsun. iki tane.

Benzer şekilde, ChartEvent olayı zaten mql5 programının kuyruğundaysa veya böyle bir olay işleniyorsa, bu türden yeni bir olay kuyruğa alınmaz.

bu yanlıştır veya bir hatadır veya bir belgeleme hatasıdır veya koşulların yetersiz ifadesidir.

Olayların tümü başarıyla sıraya alındı ve hiçbiri atılmadı. Aksi takdirde, bu konu ortaya çıkmayacaktı.

Farklı bir planla kendiminkini çözmeye çalışıyorum
 Olay kuyruğunun taşması RAM'in boyutunu nasıl etkiler? Olay kuyruğu doluysa kuyruğu taşan olaylar nereye gidiyor?

Renat ve Rosh bu soruyu zaten yanıtladı mı?
 
Rosh :

Olay atılırsa, sıraya alınmaz. Hafıza gelişmez .

Vay! Benim anlamak istediğim asıl şey buydu. Ve TheXpert'ten beri sıranın kendisine yalnızca birkaç MB harcandığını söyledi, o zaman büyük olasılıkla bellek sızıntısı başka bir yerde meydana geliyor ... Tam tersi kanıtlanana kadar bu ifadeden ilerleyeceğiz.

Roş :

Bu tür sorunlar ortaya çıkarsa, her şey çok kötüdür. Bence bellek sorunlarını aramak için son yer taşan bir olay kuyruğu.

Evet, bulabildiğim her yere bakmaya çalışıyorum.

Ancak, diskalifiye edilen üç Uzman Danışmandan en az iki Uzman Danışmanın kullanıcı olayları akışıyla çalıştığını unutmayın (üçüncünün yazarı talebe yanıt vermedi). Lizar (kullanıcı olaylarıyla çalışır) ayrıca artan RAM tüketimine sahiptir. Ve her şeyi doğru anlarsam, kullanıcı olaylarının dakikada bir kereden daha az kullanılması nedeniyle tol64'ün bellek tüketimi son derece düşük. Böylece, ister istemez, kullanıcı olayları kavramının uygulanmasının etkinliğinden şüphe edilmesi gerektiği ortaya çıktı. Kesin bir cevap alana kadar.

 
Yedelkin :

Ancak, diskalifiye edilen üç Uzman Danışmandan en az iki Uzman Danışmanın kullanıcı olayları akışıyla çalıştığını unutmayın (üçüncünün yazarı talebe yanıt vermedi). Lizar (kullanıcı olaylarıyla çalışır) ayrıca artan RAM tüketimine sahiptir. Ve her şeyi doğru anlarsam, kullanıcı olaylarının dakikada bir kereden daha az kullanılması nedeniyle tol64'ün bellek tüketimi son derece düşük. Böylece, ister istemez, kullanıcı olayları kavramının uygulanmasının etkinliğinden şüphe edilmesi gerektiği ortaya çıktı. Kesin bir cevap alana kadar.

Aynı zamanda, EA'nın çeşitli enstrümanlar ve zaman dilimlerinde başlatılan göstergelerden olaylar aldığını, yanlış hatırlamıyorsam toplamda yaklaşık 80 olduğunu unutmayalım. Her gösterge, gösterge arabellekleri için kaynak tüketir ve burası köpeğin gömülü olduğu yerdir.
 
sergeev :

o sofistike değil, basit. Eğer anlayamıyorsanız, o zaman bu benim baş ağrım değil. bu zaman

Anladığım kadarıyla akıllı olduğumu yazdım. Yoksa dokunmazdım.

sergeev :

OnChartEvent'in içinde değil, kodun her yerine dağılmış durumda. Sen kendin işine dar kısıtlamalar getiriyorsun. iki tane.

Evet, evet, EventChartCustom OnChartEvent'in içinde değil , dışındadır. Şimdi kodunuza bakalım:

 void OnChartEvent ( int iview, int id, long lparam, double dparam, string sparam)
{
     if (id== CHARTEVENT_CUSTOM +VM_IDLE)
    {
      ... 
    }
     EventChartCustom (m_chart, VM_IDLE, ( long )event_idle, 0 , "" ); // отправили событие с указанием последнего счетчика
}

Açıkçası, bu kodda EventChartCustom , OnChartEvent içinde değil ve çok yanılmışım :)

 
sergeev :

bu yanlıştır veya bir hatadır veya bir belgeleme hatasıdır veya koşulların yetersiz ifadesidir.

Olayların tümü başarıyla sıraya alındı ve hiçbiri atılmadı. Aksi takdirde, bu konu ortaya çıkmayacaktı.

En az bir sürüm daha vardır: sizin özel durumunuzda, sıra basitçe taşmaz (kodun verimliliği nedeniyle), bu nedenle olayları atma gerçekleri yoktur.

 
Yedelkin :
 

En az bir sürüm daha vardır: sizin özel durumunuzda, sıra basitçe taşmaz (kodun verimliliği nedeniyle), bu nedenle olayları atma gerçekleri yoktur.

işte aynı olayları atmama gösterimine başladığım özel durumum

https://www.mql5.com/ru/forum/5091#comment_112780

Aynı yerde neden bir taşma olduğunu yazdı.

Evet, evet, EventChartCustom OnChartEvent'in içinde değil , dışındadır. Şimdi kodunuza bakalım:

Köküne git! Sorunun bir gösterimini ve çözümünü gösterdim. Bu EventChart çağrısı, kodun herhangi bir yerinde olabilir.

 
Rosh :
Aynı zamanda, EA'nın çeşitli enstrümanlar ve zaman dilimlerinde başlatılan göstergelerden olaylar aldığını, yanlış hatırlamıyorsam toplamda yaklaşık 80 olduğunu unutmayalım. Her gösterge, gösterge arabellekleri için kaynak tüketir ve bu, köpeğin gömülü olduğu yerdir.
Japonlardan mı bahsediyorsun? Benim durumumda her şey daha basit: tek bir zaman diliminde 6 cihazda başlatılan 8 veya 15 hesaplanmış gösterge tamponlu bir evrensel gösterge. Onlar. sadece 6 gösterge. Ve teorik olarak, böyle bir şema bir haftada 2 GB'ı silip süpürebilir mi?
 
Yedelkin :
Japonlardan mı bahsediyorsun? Benim durumumda her şey daha basit: tek bir zaman diliminde 6 cihazda başlatılan 8 veya 15 hesaplanmış gösterge tamponlu bir evrensel gösterge. Onlar. sadece 6 gösterge. Ve teorik olarak, böyle bir şema bir haftada 2 GB'ı silip süpürebilir mi?
Yardımcı göstergeler için bellek tüketimini azaltma makalesini okuyun, faydalı olabilir.
 
Rosh :
Yardımcı göstergeler için bellek tüketimini azaltma makalesini okuyun, faydalı olabilir.

Teşekkür ederim, zaten orada optimize edilmiş her şeyim var :) Hatırladığım kadarıyla bu makaleyi dikkate almak dahil. Bir sonraki aydınlanma seviyesini beklememiz gerekecek :)

Ancak, kullanıcı olayları aracılığıyla birlikte çalışıyorlarsa, bir EA ve bir göstergenin ayrı ayrı ne kadar tükettiğini bir şekilde belirlemek mümkün müdür?

1234567
Yeni yorum
Neden: