// Возвращает время Обзора рынка в миллисекундах.long TimeCurrentMsc()
{
long Res = 0 ;
MqlTick Tick;
for ( int i = SymbolsTotal ( true ); i >= 0 ; i--)
{
conststring Symb = SymbolName (i, true );
if ( SymbolInfoTick (Symb, Tick) && (Tick.time_msc > Res))
Res = Tick.time_msc;
}
return (Res);
}
PS TimeCurrentMsc는 반복되는 요청에도 불구하고 어떤 이유로 MQL5에 포함되지 않습니다.
가속은 없을 것입니다. 다중 가속도를 증명하는 계산을 최소한 대략적인 수치로 제시하십시오.
자원 경쟁? 제어되지 않은 새 스레드 생성? 갑작스러운 갈등?
설명할 수 없는 브레이크를 원하십니까?
이벤트 모델에서 모든 이벤트는 항상 차례로 형성되었습니다. 씹다 - 씹었다.
비동기식 아키텍처에서 이벤트 처리 속도가 빨라지지 않습니까? 진심이야? 사용자 프로그램, 특히 해당 처리기의 처리를 가속화합니다. 이것이 우리가 말하는 것입니다. 스레드 사용을 최소화하려고 하는 것을 이해합니다. 그러나 옵션 중 하나로 각 핸들러를 별도의 스레드에서 실행하십시오. 통제되지 않은 스레드 생성이 아닙니다. 사용자 프로그램에는 몇 개의 핸들러만 있으며 프로그램이 시작될 때 각각의 핸들러는 자체 스레드에서 실행되어야 합니다. 그리고 뮤텍스 또는 무엇을 동기화하든 이미 처리기 간에 이벤트를 동기화합니다.
그러나 스레드가 당신에게 고통을 준다면, 당신이 언급한 것처럼 하나의 스레드에서 작업할 수 있는 이벤트 모델이 있습니다. 이벤트 처리 , 실행 중인 작업이 있는 이벤트 루프. 이벤트 루프는 순차적으로 회전하지만 이 루프의 작업은 병렬로 처리됩니다! 이것이 우리가 말하는 것입니다. 프로그램의 모든 핸들러는 이 이벤트 루프에서 실행되고 모든 이벤트는 비동기식으로 실시간으로 동시에 도착합니다. 즉, OnTrade 및 온북일치합니다. 이벤트 루프가 다른 언어에서 어떻게 작동하는지 관심을 가져보세요. 이벤트 루프 가 이미 터미널에 있는 경우 프로그램의 핸들러에 이벤트 루프를 적용하기만 하면 됩니다. 그게 다야.
그런 나피. 예를 들어, 다른 스레드에 내부 변수에 대한 읽기/쓰기 액세스 권한이 있는 경우 MQL 프로그램이 훨씬 더 복잡해집니다.
MQL 프로그램은 더 복잡해지지 않으며 개발자에게는 동기화 문제일 뿐입니다. 당연히 결정하고 싶은 마음이 없습니다. 또는 이 모델을 위해 설계되지 않은 프로젝트의 막다른 초기 아키텍처. 물론 아무도 새 모델을 위해 프로젝트를 다시 작성하지 않을 것입니다. 이벤트 루프모델 은 핸들러에 더 적합합니다. 이것이 내가 전달하려는 것입니다. 그리고 이 모델은 아마도 오랫동안 터미널에 있었고 핸들러에 적용되지 않았을 뿐입니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MetaTrader 5 플랫폼 빌드 2650의 새 버전: 차트의 백그라운드 로드 및 MQL5 코드 프로파일러의 개선 사항
fxsaber , 2020.11.04 16:50
불행히도 차트 창, 터미널, 마켓 워치 등을 최소화하는 기능을 추가하지 않았습니다. 이러한 창을 최소화하면 CPU 사용량이 감소한다는 이전 증거가 제공되었습니다.그리고 터미널 창이 보이지 않을 때 시장 감시 창 등으로 데이터 출력을 중지하십시오. 예를 들어, 현재 응용 프로그램(예: 브라우저)이 활성 및 최대화된 상태에 있는 경우입니다.
턱수염 필요 - 현재 선택된 차트를 결정합니다. 사람들은 목발 WinAPI 솔루션 을 사용해야 합니다.
예, MetaTrader VPS에는 호스팅 제공업체 의 일반 VPS에 비해 대기 시간(지연 시간 급증)이 몇 배나 적고 모든 리소스가 몇 배 더 많습니다.
그 이유는 여러 번 설명되었습니다.
실행 스레드는 현재(모든) 프로세서 아키텍처 내에서 제로 지연을 보장할 수 없습니다. "실시간 운영 체제"에 대한 이야기는 신화로 남아 있으며 언급할 수 없습니다.
자세한 설명 덕분에 단일 방출로 명확합니다. 현재 우리는 SymbolInfoTick이 아니라 거의 모든 틱 에 쏟아지는 다른 특성의 지연에 대해 논의하고 있습니다.
다른 질문은 "실제로 다른 의견을 의미" 하지 않고 단일 명령의 측정으로 넘어 가지 않고 한 의견에 명확하고 완전히 설명된 시나리오로만 고려할 수 있습니다.
다른 질문은 "실제로 다른 의견을 의미" 하지 않고 단일 명령의 측정으로 넘어 가지 않고 한 의견에 명확하고 완전히 설명된 시나리오로만 고려할 수 있습니다.
소스 코드의 주석을 포함하여 자세한 내용을 보려면 여기를 클릭하십시오.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MT5와 속도
fxsaber , 2020.11.05 07:42
MQ에서 VPS를 사용하는 사람은 다음 프로그램의 결과를 거기에서 공유하십시오.
그러한 플랫폼 deltix가 있습니다(광고에 표시되지 않음). 개발자들과 이야기를 나누었을 때(중재를 위해 한 번 연결하고 싶었습니다) 단일 지연에 대해 동일한 방식으로 설명했습니다. 이는 정상이며 평균적으로 지켜봐야 합니다.
그건 그렇고, 누군가의 정원에 돌이 없으면
단일 이상값은 불가피하게 발생하므로 전체 Market Watch의 배열과 모든 현재 위치/주문 의 배열을 반환하는 일반 함수를 갖는 것이 논리적입니다. MarketBookGet과 유사합니다.
이제 사이클을 실행해야 합니다. 아주 비싸요.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MT5와 속도
fxsaber , 2020.10.07 12:41
현실적 필요성 때문에 이렇게 글을 쓰게 되었습니다.
PS TimeCurrentMsc는 반복되는 요청에도 불구하고 어떤 이유로 MQL5에 포함되지 않습니다.
가속은 없을 것입니다. 다중 가속도를 증명하는 계산을 최소한 대략적인 수치로 제시하십시오.
자원 경쟁? 제어되지 않은 새 스레드 생성? 갑작스러운 갈등?
설명할 수 없는 브레이크를 원하십니까?
이벤트 모델에서 모든 이벤트는 항상 차례로 형성되었습니다. 씹다 - 씹었다.
사용자 프로그램, 특히 해당 처리기의 처리를 가속화합니다. 이것이 우리가 말하는 것입니다.
스레드 사용을 최소화하려고 하는 것을 이해합니다. 그러나 옵션 중 하나로 각 핸들러를 별도의 스레드에서 실행하십시오.
통제되지 않은 스레드 생성이 아닙니다. 사용자 프로그램에는 몇 개의 핸들러만 있으며 프로그램이 시작될 때 각각의 핸들러는 자체 스레드에서 실행되어야 합니다.
그리고 뮤텍스 또는 무엇을 동기화하든 이미 처리기 간에 이벤트를 동기화합니다.
그러나 스레드가 당신에게 고통을 준다면, 당신이 언급한 것처럼 하나의 스레드에서 작업할 수 있는 이벤트 모델이 있습니다. 이벤트 처리 , 실행 중인 작업이 있는 이벤트 루프.
이벤트 루프는 순차적으로 회전하지만 이 루프의 작업은 병렬로 처리됩니다!
이것이 우리가 말하는 것입니다. 프로그램의 모든 핸들러는 이 이벤트 루프에서 실행되고 모든 이벤트는 비동기식으로 실시간으로 동시에 도착합니다.
즉, OnTrade 및 온북 일치합니다.
이벤트 루프가 다른 언어에서 어떻게 작동하는지 관심을 가져보세요.
이벤트 루프 가 이미 터미널에 있는 경우 프로그램의 핸들러에 이벤트 루프를 적용하기만 하면 됩니다. 그게 다야.
별도의 스레드에서 각 핸들러를 실행합니다.
그런 나피. 예를 들어, 다른 스레드에 내부 변수에 대한 읽기/쓰기 액세스 권한이 있는 경우 MQL 프로그램이 훨씬 더 복잡해집니다.
그런 나피. 예를 들어, 다른 스레드에 내부 변수에 대한 읽기/쓰기 액세스 권한이 있는 경우 MQL 프로그램이 훨씬 더 복잡해집니다.
MQL 프로그램은 더 복잡해지지 않으며 개발자에게는 동기화 문제일 뿐입니다. 당연히 결정하고 싶은 마음이 없습니다.
또는 이 모델을 위해 설계되지 않은 프로젝트의 막다른 초기 아키텍처.
물론 아무도 새 모델을 위해 프로젝트를 다시 작성하지 않을 것입니다.
이벤트 루프 모델 은 핸들러에 더 적합합니다. 이것이 내가 전달하려는 것입니다.
그리고 이 모델은 아마도 오랫동안 터미널에 있었고 핸들러에 적용되지 않았을 뿐입니다.
MQL 프로그램은 더 복잡해지지 않을 것입니다...
나는 여기서 이론화를 끝낼 것을 제안합니다. 이것은 여기서 실천과 결코 교차하지 않을 것입니다.