그럼 왜 내 동결 현상이 일어나는지 말해주세요. OnTick의 내 데이터 반환은 표시기 폴링 기능으로 고정됩니다. 즉, M1에 의한 CopyTime 업데이트는 OnTick에서 나머지 처리를 시작하는 트리거 역할을 하며 CopyTime 전에 기능이나 표시기 폴링이 없습니다.
그리고 30번째 빌드 이전에는 왜 그런 문제가 없었고 2017년 10월부터 모든 것이 완벽하게 작동했습니까?
왜 개발자들은 동기화된 데이터 배열(여러 기기에 대해) 수신을 보장하는 함수를 작성하지 않아 사람들이 헛되이 시간을 낭비하지 않도록 하지 않습니까?
결국 MT5는 멋지고 편리한 도구로 자리 잡았죠?
기대된다...
네. 필요한 수의 기호 및 기간에 대한 OnCalcuate 생성자. 또는 OnCalculate 에 추가하여 예를 들어 최대 255개의 OnCalculate에 대해 "MainCalculate"와 같은 새 개체를 도입합니다. 이 개체에는 OnCalculate 개체가 존재합니다. 필요하지 않은 사람은 mtf 및 다른 문자가 필요한 이전 OnCalculate를 사용합니다. "MainCalculate"를 사용합니다. 막대의 첫 번째 및 마지막 눈금은 모든 기호 및 일치하는 기간에 대해 동일합니다. 결국 OnCalculate는 이미 개발되어 자리를 잡았고, 타임프레임 및 심볼에 대한 중개자의 다른 기능 없이 OnCalculate 집계를 통해 제3자 심볼 및 타임프레임에 대한 모든 액세스를 추론하는 것이 논리적입니다.
지표가 틱의 수신/중첩 속도를 뻔뻔하게 늦추고 틱당 수백 밀리초 또는 심지어 몇 초를 소비할 때 데이터를 사용할 수 있는 위치(특히 보장됨)에 대해 생각해 보십시오. 결과적으로 CPU가 시간에 따라 틱을 처리하기에 충분하지 않아 적자가 누적되고 이에 따라 차트 기록이 느려집니다.
'보증금'을 물으신다면 '아무것도 알고 싶지 않고, 계속 쓰고 싶은 대로, 성능과 잠금은 생각하지 않고, 그냥 줘'라고 하는 요청일 가능성이 큽니다.
수백만 개의 막대를 사용할 수 있을 때 자신과 다른 사람의 지표의 성과에 대해 생각해 보십시오. 잘못 쓰여지고 값비싼 지표는 해당 기호 차트의 업데이트 속도를 쉽게 늦출 수 있습니다.
시작하려면 OnCalculate가 실행되는 시간 을 마이크로초 단위로 측정 하십시오. 그런 다음 1초를 평균 틱 시간으로 나누어 표시기의 최대 처리량(초당 틱 수)을 구합니다.
지표가 틱의 수신/중첩 속도를 뻔뻔하게 늦추고 틱당 수백 밀리초 또는 심지어 몇 초를 소비할 때 데이터를 사용할 수 있는 위치(특히 보장됨)에 대해 생각해 보십시오. 결과적으로 CPU가 시간에 따라 틱을 처리하기에 충분하지 않아 적자가 누적되고 이에 따라 차트 기록이 느려집니다.
'보증금'을 물으신다면 '아무것도 알고 싶지 않고, 계속 쓰고 싶은 대로, 성능과 잠금은 생각하지 않고, 그냥 줘'라고 하는 요청일 가능성이 큽니다.
수백만 개의 막대를 사용할 수 있을 때 자신과 다른 사람의 지표의 성과에 대해 생각해 보십시오. 잘못 쓰여지고 값비싼 지표는 해당 기호 차트의 업데이트 속도를 쉽게 늦출 수 있습니다.
시작하려면 OnCalculate가 실행되는 시간을 마이크로초 단위로 측정하십시오. 그런 다음 1초를 평균 틱 시간으로 나누어 표시기의 최대 처리량(초당 틱 수)을 구합니다.
이것은 즉시 정신을 차리게 합니다.
항상 초고속이 필요한 것은 아닙니다. 작업의 편의성도 매우 중요합니다. 이제 다중 통화 표시기 를 작성하는 것은 "수동 일몰"입니다. MT4에서도 느리지만 항상 i-function을 통과할 수 있기 때문에 더 쉬웠습니다. , 그러나 얻으려면, 그러나 MT5 데이터에서는, 즉 거기에 있지 않으며 여전히 특수 코드를 직접 보호해야 합니다.
또한 모든 사용자가 고급 프로그래머는 아니며 일부 사용자는 초음속이 아니더라도 편리하고 안정적인 툴킷이 필요하며 포트폴리오 시스템의 경우 일반적으로 이러한 속도가 필요하지 않으며 수백만 개의 막대가 필요하지 않습니다. 이 경우 최대 처리량은 중요하지 않습니다. 정확하게 작동하는 것이 중요하며 실제로 이것은 제품을 더 대중적이고 더 쉽게 접근할 수 있게 만드는 요소입니다.
MT5의 i-function의 출현은 상황을 어떤 식으로든 개선했지만 문제를 해결하지 못했습니다. 여러 악기에 대해 쉽고 간단하게 동기화된 어레이를 가져오고 얻을 수 있는 방법이 없습니다. 아마도 모든 사람이 이것을 필요로 하지는 않을 것입니다. 어쩌면 이것이 우선순위가 아니라 이해는 되지만 그런 과업이 있습니다.
그럼 왜 내 동결 현상이 일어나는지 말해주세요. OnTick의 내 데이터 반환은 표시기 폴링 기능으로 고정됩니다. 즉, M1에 의한 CopyTime 업데이트는 OnTick에서 나머지 처리를 시작하는 트리거 역할을 하며 CopyTime 전에 기능이나 표시기 폴링이 없습니다.
그리고 30번째 빌드 이전에는 왜 그런 문제가 없었고 2017년 10월부터 모든 것이 완벽하게 작동했습니까?
제가 제안한 대로 해주세요.
그렇지 않으면 100% 재생산을 위한 전체 자료가 필요합니다.왜 개발자들은 동기화된 데이터 배열(여러 기기에 대해) 수신을 보장하는 함수를 작성하지 않아 사람들이 헛되이 시간을 낭비하지 않도록 하지 않습니까?
결국 MT5는 멋지고 편리한 도구로 자리 잡았죠?
기대된다...
또한 다른 사람의 시간 프레임으로 작업하는 경우 1분에 한 번 이 시간 프레임(모든 CopyXXXX 기능)에서 OHLC를 수신해야 한다는 것이 항상 권장되었습니다. 항상 그래왔다.
슬라바는 2분마다 말했습니다. 보기에는 너무 게으르지만 정확히 기억합니다.
왜 개발자들은 동기화된 데이터 배열(여러 기기에 대해) 수신을 보장하는 함수를 작성하지 않아 사람들이 헛되이 시간을 낭비하지 않도록 하지 않습니까?
결국 MT5는 멋지고 편리한 도구로 자리 잡았죠?
기대된다...
네. 필요한 수의 기호 및 기간에 대한 OnCalcuate 생성자. 또는 OnCalculate 에 추가하여 예를 들어 최대 255개의 OnCalculate에 대해 "MainCalculate"와 같은 새 개체를 도입합니다. 이 개체에는 OnCalculate 개체가 존재합니다. 필요하지 않은 사람은 mtf 및 다른 문자가 필요한 이전 OnCalculate를 사용합니다. "MainCalculate"를 사용합니다. 막대의 첫 번째 및 마지막 눈금은 모든 기호 및 일치하는 기간에 대해 동일합니다. 결국 OnCalculate는 이미 개발되어 자리를 잡았고, 타임프레임 및 심볼에 대한 중개자의 다른 기능 없이 OnCalculate 집계를 통해 제3자 심볼 및 타임프레임에 대한 모든 액세스를 추론하는 것이 논리적입니다.
지표가 틱의 수신/중첩 속도를 뻔뻔하게 늦추고 틱당 수백 밀리초 또는 심지어 몇 초를 소비할 때 데이터를 사용할 수 있는 위치(특히 보장됨)에 대해 생각해 보십시오. 결과적으로 CPU가 시간에 따라 틱을 처리하기에 충분하지 않아 적자가 누적되고 이에 따라 차트 기록이 느려집니다.
'보증금'을 물으신다면 '아무것도 알고 싶지 않고, 계속 쓰고 싶은 대로, 성능과 잠금은 생각하지 않고, 그냥 줘'라고 하는 요청일 가능성이 큽니다.
수백만 개의 막대를 사용할 수 있을 때 자신과 다른 사람의 지표의 성과에 대해 생각해 보십시오. 잘못 쓰여지고 값비싼 지표는 해당 기호 차트의 업데이트 속도를 쉽게 늦출 수 있습니다.
시작하려면 OnCalculate가 실행되는 시간 을 마이크로초 단위로 측정 하십시오. 그런 다음 1초를 평균 틱 시간으로 나누어 표시기의 최대 처리량(초당 틱 수)을 구합니다.
이것은 즉시 정신을 차리게 합니다.
슬라바는 2분마다 말했습니다. 보기에는 너무 게으르지만 정확히 기억합니다.
기억하지만 항상 1분 간격을 사용합니다. 그래서 더 신뢰할 수 있습니다.
실례지만, 이 경우 M15 타임프레임의 기록 깊이는 120바였습니다. 그리고 이것은 MQL5에 이미 중요합니까?
재생 가능한 콘텐츠를 제공하지 않았습니다.
다른 사람의 기호 에 브레이크 표시기가 있으면 다른 사람의 데이터에 액세스하는 기능이 느려지는 이유를 설명했습니다. 차트의 다른 지표를 완전히 무시하고 특정 통화 사례에 대해 이야기하고 있습니다. 즉, 특히 이것에 대해 명확하게 썼기 때문에 시작해야했습니다.
기술 세부 사항 및 전문가와 지표 목록이 완전히 부재한 상태에서 선동 및 비교 진술에 참여하지 마십시오.
플레이할 코드를 주세요.
***
그래서 어떻게 뭔가를 재현? 플레이할 데이터를 주세요.
물론 여기에 모든 코드를 넣을 수는 없으며 문제가 발생한 섹션을 이미 표시했으므로 다시 수행하겠습니다.
전체 코드 또는 더 나은 방법은 아무 말도 하지 마십시오. 전체 코드가 없으면 공기를 흔드는 것만으로도 충분합니다.
지표가 틱의 수신/중첩 속도를 뻔뻔하게 늦추고 틱당 수백 밀리초 또는 심지어 몇 초를 소비할 때 데이터를 사용할 수 있는 위치(특히 보장됨)에 대해 생각해 보십시오. 결과적으로 CPU가 시간에 따라 틱을 처리하기에 충분하지 않아 적자가 누적되고 이에 따라 차트 기록이 느려집니다.
'보증금'을 물으신다면 '아무것도 알고 싶지 않고, 계속 쓰고 싶은 대로, 성능과 잠금은 생각하지 않고, 그냥 줘'라고 하는 요청일 가능성이 큽니다.
수백만 개의 막대를 사용할 수 있을 때 자신과 다른 사람의 지표의 성과에 대해 생각해 보십시오. 잘못 쓰여지고 값비싼 지표는 해당 기호 차트의 업데이트 속도를 쉽게 늦출 수 있습니다.
시작하려면 OnCalculate가 실행되는 시간을 마이크로초 단위로 측정하십시오. 그런 다음 1초를 평균 틱 시간으로 나누어 표시기의 최대 처리량(초당 틱 수)을 구합니다.
이것은 즉시 정신을 차리게 합니다.
항상 초고속이 필요한 것은 아닙니다. 작업의 편의성도 매우 중요합니다. 이제 다중 통화 표시기 를 작성하는 것은 "수동 일몰"입니다. MT4에서도 느리지만 항상 i-function을 통과할 수 있기 때문에 더 쉬웠습니다. , 그러나 얻으려면, 그러나 MT5 데이터에서는, 즉 거기에 있지 않으며 여전히 특수 코드를 직접 보호해야 합니다.
또한 모든 사용자가 고급 프로그래머는 아니며 일부 사용자는 초음속이 아니더라도 편리하고 안정적인 툴킷이 필요하며 포트폴리오 시스템의 경우 일반적으로 이러한 속도가 필요하지 않으며 수백만 개의 막대가 필요하지 않습니다. 이 경우 최대 처리량은 중요하지 않습니다. 정확하게 작동하는 것이 중요하며 실제로 이것은 제품을 더 대중적이고 더 쉽게 접근할 수 있게 만드는 요소입니다.
MT5의 i-function의 출현은 상황을 어떤 식으로든 개선했지만 문제를 해결하지 못했습니다. 여러 악기에 대해 쉽고 간단하게 동기화된 어레이를 가져오고 얻을 수 있는 방법이 없습니다. 아마도 모든 사람이 이것을 필요로 하지는 않을 것입니다. 어쩌면 이것이 우선순위가 아니라 이해는 되지만 그런 과업이 있습니다.
함수: GetSyncData
입력: 악기 목록, 기간, 막대 범위 및/또는 날짜 범위
출력: 모든 악기의 인덱스가 동일한 시간에 해당하도록 MqlRates 요소가 있는 배열