우리는 더 이상 당황하기 위해 서두르고 현실을 벌레라고 부르며 우리를 비난하는 사람들을 용납하지 않습니다. 분명히 더 많은 구성 요소가 있을 것입니다.
주제의 약간 오른쪽, OnTimer() )))
어디서 읽었는지 기억이 안나는데 , 거기에 MQ의 대표자는 시스템을 1ms의 지연으로 전송하는 것이 가능하다고 썼습니다. 그런 다음 EventSetMillisecondTimer(...)를 사용하는 것 같습니다. 그러면 OnTimer()도 16ms가 아닌 약 1ms의 오류로 작동합니다.
내가 올바르게 이해했다면 OnTimer()는 시스템 지연과 함께 작동합니다. 맞습니까?
추신. 어제 서비스 데스크에 요청을 보냈습니다 처리되지 않음,시작됨: 2018.07.30 12:52,#2117844, 처리에 도움을 줄 수 있습니까? 그렇지 않으면 어제부터 중단됨))
OnTimer 는 GetTickCount WinAPI 함수 를 통해 제어되는 시스템 WinAPI 타이머의 오류와 함께 작동합니다. 이것은 측정된 프로세스에 최소한의 영향을 미치는 매우 빠르고 저렴한 시간 측정 방법입니다. 즉, 소비로 최종 결과를 크게 망치지 않습니다.
이 타이머의 정확도는 전체 운영 체제에 대해 증가할 수 있지만 CPU 소비 증가와 많은 프로그램이 시작된다는 사실로 인한 무작위 및 대량 유발 효과 모두에서 이에 대한 비용을 지불해야 합니다.
시간을 정확하게 측정하다
슬립에서 시간을 덜 보내다
정상적인 오류에 대해 작동하는 일부 시간 초과는 솔직히 잘못된 동작으로 변질됩니다.
그리고 더 많은 멋진 결함
Windows 시스템 타이머 문제는 20년이 넘었습니다. 그러나 이전 타이머의 동작과 정확도를 변경하는 것은 위험합니다.
따라서 새롭고 보다 정확한 시간 측정 방법이 오랫동안 도입되었습니다. 그러나 리소스 집약적이며 이전 타이머를 완전히 대체하는 데 사용하는 것은 현명하지 않습니다.
GetMicrosecondCount를 사용하여 구현된 고정밀 타이머가 있습니다. GetTickCount보다 더 비싸다는 것을 이해하고 의식적으로 사용해야 합니다. 또한 정확한 측정의 경우 GetMicrosecondCount에 대한 호출 비용을 명시적으로 고려해야 합니다.
타이머를 오용하고 벤치마크를 깨끗하게 유지하여 자신과 다른 사람을 속이는 것은 매우 쉽습니다.
OnTimer 는 GetTickCount WinAPI 함수 를 통해 제어되는 시스템 WinAPI 타이머의 오류와 함께 작동합니다. 이것은 측정된 프로세스에 최소한의 영향을 미치는 매우 빠르고 저렴한 시간 측정 방법입니다. 즉, 소비로 최종 결과를 크게 망치지 않습니다.
이 타이머의 정확도는 전체 운영 체제에 대해 증가할 수 있지만 CPU 소비 증가와 많은 프로그램이 시작된다는 사실로 인한 무작위 및 대량 유발 효과 모두에서 이에 대한 비용을 지불해야 합니다.
시간을 정확하게 측정하다
슬립에서 시간을 덜 보내다
정기적인 시간 초과에 대해 작동하는 일부 시간 초과는 솔직히 잘못된 동작으로 변질됩니다.
그리고 더 많은 멋진 결함
Windows 시스템 타이머 문제는 20년이 넘었습니다. 그러나 이전 타이머의 동작과 정확도를 변경하는 것은 위험합니다.
따라서 새롭고 보다 정확한 시간 측정 방법이 오랫동안 도입되었습니다. 그러나 리소스 집약적이며 이전 타이머를 완전히 대체하는 데 사용하는 것은 현명하지 않습니다.
GetMicrosecondsCount를 사용하여 구현된 고정밀 타이머가 있습니다. GetTickCount보다 더 비싸다는 것을 이해하고 의식적으로 사용해야 합니다. 또한 정확한 측정의 경우 GetMicrosecondsCount에 대한 호출 비용을 명시적으로 고려해야 합니다.
타이머를 오용하고 벤치마크를 깨끗하게 유지하여 자신과 다른 사람을 속이는 것은 매우 쉽습니다.
ATP, MQ 대표가 시스템 타이머 시간 단축에 대해 쓴 후 생각한 것입니다))
그래서 나는 이 방향으로 아무것도 바꿀 필요가 없다고 지지한다
그건 그렇고, 나는 C #에서와 같이 또는 적어도 부스트에서와 같이 리플렉션 방향으로 발전이 있는지 알고 싶습니다. 예를 들어 직렬화/역직렬화를 구현하는 것이 더 편리합니다.
마이크로초 단위로 시간을 측정하는 데 사용되는 GetMicrosecondsCount에 대한 두 번의 호출 사이에 컴퓨터의 현지 시간이 변경되었을 확률은 얼마입니까?
제로가 아닙니다.
매우 건설적인 대화
5명의 투수를 영원히 제거하면 됩니다.
우리는 더 이상 당황하여 서두르는 사람들을 용납하지 않고 WinAPI 기능의 현실을 버그라고 부르고 우리를 비난하려고 합니다. 분명히 더 많은 구성 요소가 있을 것입니다.
제로가 아닙니다.
그리고 클라이언트/서버 정보 교환을 위한 시간 손실 확률(밀리초)은 얼마입니까? 아마도 현지 시간 으로 변경될 확률보다 더 많을 것입니다.
5명의 투수를 영원히 제거하면 됩니다.
우리는 더 이상 당황하기 위해 서두르고 현실을 벌레라고 부르며 우리를 비난하는 사람들을 용납하지 않습니다. 분명히 더 많은 구성 요소가 있을 것입니다.
주제의 약간 오른쪽, OnTimer() )))
어디서 읽었는지 기억이 안나는데 , 거기에 MQ의 대표자는 시스템을 1ms의 지연으로 전송하는 것이 가능하다고 썼습니다. 그런 다음 EventSetMillisecondTimer(...)를 사용하는 것 같습니다. 그러면 OnTimer()도 16ms가 아닌 약 1ms의 오류로 작동합니다.
내가 올바르게 이해했다면 OnTimer()는 시스템 지연과 함께 작동합니다. 맞습니까?
추신. 어제 서비스 데스크에 요청을 보냈습니다 처리되지 않음 , 시작됨: 2018.07.30 12:52 , #2117844 , 처리에 도움을 줄 수 있습니까? 그렇지 않으면 어제부터 중단됨))OnTimer 는 GetTickCount WinAPI 함수 를 통해 제어되는 시스템 WinAPI 타이머의 오류와 함께 작동합니다. 이것은 측정된 프로세스에 최소한의 영향을 미치는 매우 빠르고 저렴한 시간 측정 방법입니다. 즉, 소비로 최종 결과를 크게 망치지 않습니다.
이 타이머의 정확도는 전체 운영 체제에 대해 증가할 수 있지만 CPU 소비 증가와 많은 프로그램이 시작된다는 사실로 인한 무작위 및 대량 유발 효과 모두에서 이에 대한 비용을 지불해야 합니다.
Windows 시스템 타이머 문제는 20년이 넘었습니다. 그러나 이전 타이머의 동작과 정확도를 변경하는 것은 위험합니다.
따라서 새롭고 보다 정확한 시간 측정 방법이 오랫동안 도입되었습니다. 그러나 리소스 집약적이며 이전 타이머를 완전히 대체하는 데 사용하는 것은 현명하지 않습니다.
GetMicrosecondCount를 사용하여 구현된 고정밀 타이머가 있습니다. GetTickCount보다 더 비싸다는 것을 이해하고 의식적으로 사용해야 합니다. 또한 정확한 측정의 경우 GetMicrosecondCount에 대한 호출 비용을 명시적으로 고려해야 합니다.
타이머를 오용하고 벤치마크를 깨끗하게 유지하여 자신과 다른 사람을 속이는 것은 매우 쉽습니다.
우리는 더 이상 당황하여 서두르는 사람들을 용납하지 않고 WinAPI 기능의 현실을 버그라고 부르고 우리를 비난하려고 합니다. 분명히 더 많은 구성 요소가 있을 것입니다.
GetMicrosecondsCount가 컴퓨터의 현지 시간 에 의존하고 수정될 때 적절하게 작동하지 않을 수 있다는 도움말을 작성하면 됩니다. 그리고 GetTickCount는 의존하지 않습니다.
문제를 고려한 마이크로초 측정 작업도 약간 서툴기는 하지만 해결할 수 있습니다. 우리 수준과 당신의 수준에서 해결할 수 있습니다. 분명히 우리를 결정해야합니다.
왜 뭔가를 금지?
OnTimer 는 GetTickCount WinAPI 함수 를 통해 제어되는 시스템 WinAPI 타이머의 오류와 함께 작동합니다. 이것은 측정된 프로세스에 최소한의 영향을 미치는 매우 빠르고 저렴한 시간 측정 방법입니다. 즉, 소비로 최종 결과를 크게 망치지 않습니다.
이 타이머의 정확도는 전체 운영 체제에 대해 증가할 수 있지만 CPU 소비 증가와 많은 프로그램이 시작된다는 사실로 인한 무작위 및 대량 유발 효과 모두에서 이에 대한 비용을 지불해야 합니다.
Windows 시스템 타이머 문제는 20년이 넘었습니다. 그러나 이전 타이머의 동작과 정확도를 변경하는 것은 위험합니다.
따라서 새롭고 보다 정확한 시간 측정 방법이 오랫동안 도입되었습니다. 그러나 리소스 집약적이며 이전 타이머를 완전히 대체하는 데 사용하는 것은 현명하지 않습니다.
GetMicrosecondsCount를 사용하여 구현된 고정밀 타이머가 있습니다. GetTickCount보다 더 비싸다는 것을 이해하고 의식적으로 사용해야 합니다. 또한 정확한 측정의 경우 GetMicrosecondsCount에 대한 호출 비용을 명시적으로 고려해야 합니다.
타이머를 오용하고 벤치마크를 깨끗하게 유지하여 자신과 다른 사람을 속이는 것은 매우 쉽습니다.
ATP, MQ 대표가 시스템 타이머 시간 단축에 대해 쓴 후 생각한 것입니다))
그래서 나는 이 방향으로 아무것도 바꿀 필요가 없다고 지지한다
그건 그렇고, 나는 C #에서와 같이 또는 적어도 부스트에서와 같이 리플렉션 방향으로 발전이 있는지 알고 싶습니다. 예를 들어 직렬화/역직렬화를 구현하는 것이 더 편리합니다.
GetMicrosecondsCount가 컴퓨터의 현지 시간에 의존하고 수정될 때 적절하게 작동하지 않을 수 있다는 도움말을 작성하면 됩니다. 그리고 GetTickCount는 의존하지 않습니다.
도움말에 다음과 같이 나와 있습니다. GetMicrosecondCount() 함수는 MQL5 프로그램 시작 이후 경과된 마이크로초 수를 반환합니다 .
그래서 내가 분명히 말했습니다. 시간의 간격을 측정하는 것입니다.
문제를 고려한 마이크로초 측정 작업도 약간 서툴기는 하지만 해결할 수 있습니다. 우리 수준과 당신의 수준에서 해결할 수 있습니다. 분명히 우리를 결정해야합니다.
왜 뭔가를 금지?
금지해야합니다.
첫째, 마이크로초 타이머는 타이밍에 문제가 없습니다. 둘째, 어떤 사람들에게는 던질 이유를 생각해내고는 그것을 끝까지 붙잡는 것이 정말 가렵습니다.
다시, 규칙이 변경되었습니다.
더 이상 모욕이나 "당신은해야합니다"는 받아 들여지지 않을 것입니다. 경고 없이 청소해 드립니다.
도움말에 다음과 같이 나와 있습니다. GetMicrosecondCount() 함수는 MQL5 프로그램 시작 이후 경과된 마이크로초 수를 반환합니다.
GetTickCount 함수의 경우 다음 과 같이 작성됩니다.
GetTickCount() 함수는 시스템이 시작된 후 경과된 밀리초 수를 반환합니다.
구문은 거의 동일하지만 한 기능은 현지 시간에 의존하고 다른 기능은 그렇지 않습니다. 우리는 그것을 어떻게 알아내야 합니까?
GetTickCount 함수의 경우 다음 과 같이 작성됩니다.
구문은 거의 동일하지만 한 기능은 현지 시간에 의존하고 다른 기능은 그렇지 않습니다. 우리는 그것을 어떻게 알아내야 합니까?
WinAPI가 그렇습니다.
명시적 또는 묵시적 형태로 "should"라는 문구의 사용에 대해 상기시켜 드리겠습니다. "고려해주세요" 대신 "메타따옴표"를 사용하는 것은 더 이상 허용되지 않습니다.