이벤트의 흐름. 유휴 이벤트를 제어하고 만드는 방법은 무엇입니까? (+ 결정) - 페이지 3

새 코멘트
 

Yedelkin :

마찬가지로 ChartEvent 이벤트가 이미 mql5 프로그램 의 대기열에 있거나 이러한 이벤트가 처리 중인 경우 이 유형의 새 이벤트는 대기열에 추가되지 않습니다 .

흠. 정말 나쁩니다. 이것은 이론적으로 칠면조와 고문이 이벤트를 독립적으로 사용하는 경우 여기 저기에 공백이 있을 수 있음을 의미합니다.

그런 다음 이벤트를 데이터를 전송하는 안정적인 방법으로 사용하는 것은 의미가 없습니다.

피찰.

 
sergeev :

귀하의 질문은 "대기열이 오버플로되지 않도록 사용자 이벤트 를 대략 얼마나 자주 발송해야 하는지"입니다.

첫 페이지의 내 대답은 "OnChartEvent 호출 빈도"입니다.

즉, 하나의 이벤트 - 하나의 OnChartEvent입니다. 그 사이에 2개 이상의 이벤트가 있어서는 안 됩니다.

그것이 수학의 전부입니다.

다시, 첫 페이지를 읽으십시오. 사용자 이벤트 대신 터미널 이벤트가 처리될 때 사용자 이벤트가 누적되는 것을 방지하는 방법을 보여주었습니다. 모든 것이 간단합니다.

다시 한번, 정중하게 :) 당신은 당신의 문제를 해결했습니다. 나는 다른 계획 의 내 문제를 해결하려고 노력하고 있습니다. 토론을 읽을 때 내 질문에 대한 답을 찾지 못했습니다. 내 주요 질문(RAM 소비에 관한)에 아직 답변하지 않으셨습니다(이미 답변하기로 약속한 경우).

내가 설명한다. 나는 "특정 기능을 업데이트하지만 MQL이 타이머로 제안한 것보다 빠르다"는 작업에 직면하지 않습니다. 특히 그러한 복잡한 방식으로 결국 제안됩니다. EA 및 사용자 이벤트 처리기 기능이 있는 별도의 차트를 폭격하는 틱 빈도가 있는 여러 차트의 사용자 이벤트가 있습니다. 따라서 협소하게 초점을 맞춘 작업( OnChartEvent 내부 의 EventChartCustom)을 해결한 결과는 사용자 지정 이벤트 작업 방식과 전혀 맞지 않습니다.

 

Yedelkin :

내가 설명한다. 나는 "특정 기능을 업데이트하지만 MQL이 타이머로 제안한 것보다 빠르다"는 작업에 직면하지 않습니다. 특히 그러한 복잡한 방식으로 결국 제안됩니다. EA 및 사용자 이벤트 처리기 기능이 있는 별도의 차트를 폭격하는 틱 빈도가 있는 여러 차트의 사용자 이벤트가 있습니다. 따라서 협소하게 초점을 맞춘 작업( OnChartEvent 내부 의 EventChartCustom)을 해결한 결과는 사용자 지정 이벤트 작업 방식과 전혀 맞지 않습니다.

그는 정교하지 않지만 단순합니다. 당신이 그것을 이해할 수 없다면 이것은 내 두통이 아닙니다. 이 시간

OnChartEvent 내부가 아니라 코드 전체에 흩어져 있습니다. 당신은 자신의 작업에 대한 좁은 제한을 제시합니다. 그것은 두입니다.

마찬가지로, ChartEvent 이벤트가 이미 mql5 프로그램 의 대기열에 있거나 이러한 이벤트가 처리 중인 경우 이 유형의 새 이벤트는 대기열에 포함되지 않습니다.

이것은 올바르지 않거나 버그 또는 문서 오류 또는 조건의 과소 진술입니다.

이벤트가 모두 성공적으로 대기열에 추가되고 이벤트가 삭제되지 않습니다. 그렇지 않으면 이 스레드가 나타나지 않았을 것입니다.

나는 다른 계획의 내 자신을 해결하려고 노력 중이야
 이벤트 큐의 오버플로가 RAM 크기에 어떤 영향을 줍니까? 이벤트 큐가 가득 차면 큐를 넘친 이벤트는 어디로 가나요?

Renat와 Rosh는 이미 이 질문에 답했습니까?
 
Rosh :

이벤트가 삭제되면 단순히 대기열에 포함되지 않습니다. 메모리가 증가하지 않습니다 .

휴! 그것이 내가 이해하고 싶었던 주요 내용입니다. 그리고 엑스퍼트 이후로 대기열 자체에서 몇 MB만 소비한다고 말한 다음, 메모리 누수가 다른 곳에서 발생할 가능성이 큽니다... 반대가 입증될 때까지 이 설명에서 계속 진행합니다.

로쉬 :

그러한 문제가 발생하면 모든 것이 매우 나쁩니다. 오버플로 이벤트 큐가 메모리 문제를 찾는 마지막 장소라고 생각합니다.

예, 가능한 모든 곳을 보려고 노력합니다.

그러나 자격을 상실한 3명의 전문가 고문 중 최소 2명의 전문가 고문이 사용자 이벤트 스트림과 함께 작업했습니다(세 번째 작성자는 요청에 응답하지 않음). Lizar(사용자 이벤트와 함께 작동)도 RAM 소비가 증가했습니다. 그리고 tol64는 모든 것을 올바르게 이해한다면 사용자 이벤트가 1분에 한 번 미만으로 사용된다는 사실로 인해 메모리 소비가 매우 낮습니다. 따라서 기꺼이 사용자 이벤트 개념 구현의 효율성을 의심해야 합니다. 확실한 답을 얻을 때까지.

 
Yedelkin :

그러나 자격을 상실한 3명의 전문가 고문 중 최소 2명의 전문가 고문이 사용자 이벤트 스트림과 함께 작업했습니다(세 번째 작성자는 요청에 응답하지 않음). Lizar(사용자 이벤트와 함께 작동)도 RAM 소비가 증가했습니다. 그리고 tol64는 모든 것을 올바르게 이해한다면 사용자 이벤트가 1분에 한 번 미만으로 사용된다는 사실로 인해 메모리 소비가 매우 낮습니다. 따라서 기꺼이 사용자 이벤트 개념 구현의 효율성을 의심해야 합니다. 확실한 답을 얻을 때까지.

동시에, 제 기억이 맞다면 EA가 다양한 도구와 기간(총 약 80개)에서 시작된 지표로부터 이벤트를 수신했다는 사실을 잊지 마십시오. 각 표시기는 표시기 버퍼에 대한 리소스를 소비하며 여기에 개가 묻혀 있습니다.
 
sergeev :

그는 정교하지 않지만 단순합니다. 당신이 그것을 이해할 수 없다면 이것은 내 두통이 아닙니다. 이 시간

내가 그것을 이해하면서 나는 내가 현명하다고 썼습니다. 그렇지 않으면 만지지 않을 것입니다.

세르게예프 :

OnChartEvent 내부가 아니라 코드 전체에 흩어져 있습니다. 당신은 자신의 작업에 대한 좁은 제한을 제시합니다. 그것은 두입니다.

예, 예, EventChartCustom 은 OnChartEvent 내부가 아니라 외부에 있습니다. 이제 코드를 살펴보겠습니다.

 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 , "" ); // отправили событие с указанием последнего счетчика
}

분명히, 이 코드 에서 EventChartCustom 은 OnChartEvent 내부에 있지 않으며 제가 매우 틀렸습니다. :)

 
세르게예프 :

이것은 올바르지 않거나 버그 또는 문서 오류 또는 조건의 과소 진술입니다.

이벤트는 모두 성공적으로 큐에 대기되고 아무 것도 버려지지 않습니다. 그렇지 않으면 이 스레드가 나타나지 않았을 것입니다.

적어도 하나의 버전이 더 있습니다. 특정 경우에 큐는 단순히 오버플로되지 않으므로(코드의 효율성으로 인해) 이벤트를 폐기한다는 사실이 없습니다.

 
Yedelkin :
 

적어도 하나의 버전이 더 있습니다. 특정 경우에 큐는 단순히 오버플로되지 않으므로(코드의 효율성으로 인해) 이벤트를 폐기한다는 사실이 없습니다.

다음은 동일한 이벤트를 버리지 않는 데모를 시작한 특정 사례입니다.

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

같은 장소에 오버플로가 있는 이유를 썼습니다.

예, 예, EventChartCustom은 OnChartEvent 내부가 아니라 외부에 있습니다. 이제 코드를 살펴보겠습니다.

루트로 이동! 나는 문제와 그 해결책의 시연을 보여주었다. 이 EventChart 호출은 코드의 모든 위치에 있을 수 있습니다.

 
Rosh :
동시에, 제 기억이 맞다면 EA가 다양한 도구와 기간(총 약 80개)에서 시작된 지표로부터 이벤트를 수신했다는 사실을 잊지 마십시오. 각 표시기는 표시기 버퍼 에 대한 리소스를 소비하며 여기에 개가 묻혀 있습니다.
일본말하는거야? 글쎄요, 제 경우에는 모든 것이 더 간단합니다. 8개 또는 15개의 계산된 지표 버퍼가 있는 하나의 범용 지표로, 한 시간 프레임에 6개의 기기에서 실행됩니다. 저것들. 단 6개의 지표. 그리고 이론적으로 그러한 계획이 일주일에 2GB를 집어삼킬 수 있습니까?
 
Yedelkin :
일본말하는거야? 글쎄요, 제 경우에는 모든 것이 더 간단합니다. 8개 또는 15개의 계산된 지표 버퍼가 있는 하나의 범용 지표로, 한 시간 프레임에 6개의 기기에서 실행됩니다. 저것들. 단 6개의 지표. 그리고 이론적으로 그러한 계획이 일주일에 2GB를 집어삼킬 수 있습니까?
보조 표시기의 메모리 소비 줄이기 기사를 읽으십시오. 유용할 수 있습니다.
 
Rosh :
보조 표시기의 메모리 소비 줄이기 기사를 읽으십시오. 유용할 수 있습니다.

감사합니다. 저는 이미 거기에 모든 것이 이미 최적화되어 있습니다. :) 이 기사를 포함하여 제가 기억하는 한. 다음 단계의 깨달음을 기다려야 합니다. :)

그러나 EA와 지표가 사용자 이벤트를 통해 함께 작동한다면 어떻게 든 개별적으로 소비하는 양을 결정할 수 있습니까?

1234567
새 코멘트