MT5 코드 프로파일러 정보 - 페이지 4

 
Renat Fatkhullin :

표준 배포판에서 아무 코드나 가져와서 프로파일링하고 이를 기반으로 질문하십시오. 이를 통해 상황을 재현 가능하게 평가하고 정확한 답변을 제공할 수 있습니다.

그렇지 않으면 코드의 작은 부분이 프로파일러 보고서를 담당하는 것은 좋지 않습니다. 모든 코드를 완전히 다른 뒤죽박죽 인라인 표현으로 바꾸는 거대한 최적화 작업이 있습니다.

재생산 없이는 정확한 답이 없다는 것을 이해합니다.

표준 코드를 프로파일링할 것 같지는 않지만 재현 가능한 부분을 제공하려고 노력할 것입니다.

 
Andrey Khatimlianskii :

답변 감사합니다!

1) 나는 그것을 심플코드로 재현할 것 같지 않다, 네. 그리고 전체 프로젝트는 줄 준비가되어 있지 않습니다.

2) 이 특별한 경우에 동의합니다.

그러나 동일하거나 유사한 검사를 사용하는 다른 클래스가 많이 있으며 TimeCurrent 또는 GetTickCount는 필수 불가결합니다.
같은 값을 여러 번 요청하지 않도록 호출을 최적화하는 방법은 무엇입니까?

그리고 TimeCurrent가 실제로 너무 무거워서 계산이 정말 많은 배경에서도 눈에 띌 수 있습니까(1~5분에 한 번씩 수행되지만)?
아니면 제가 또 잘못 이해해서 전체 CPU의 38.16% / Self CPU의 26.07%를 if 체크 자체( TimeCurrent 함수 호출 제외)가 차지한 건가요? 그런데 이게 왜 그럴까요?


1) 왜 이렇게 과식하는 여는 브래킷을 이해하는 데 도움이되지 않습니다. 어떻게 해석할까요?

2) 이제 SelfCPU 정보가 명확해졌습니다. 감사합니다. 이것은 호출된 함수를 고려하지 않은 함수 코드에 대한 부하입니다.

이것은 또한 iTime 라인의 낮은 SelfCPU를 설명합니다. 매우 드물게 도달했으며 거의 호출되지 않았습니다.

그런데 왜 이렇게 큰 TotalCPU가 있습니까? 아니면 전체 프로그램에서 모든 iTime(및 기타 CopyXXX 기능?)의 로드를 표시합니까?

  1. 여는 괄호 - 일반적으로 여러 배치 지침과 특히 지역 변수 초기화에 걸쳐 있는 함수 프롤로그로 생각하십시오.
    함수의 지역 변수 볼륨에 주의를 기울일 가치가 있습니다. 호출된 변수의 인라인으로 인해 볼륨이 증가할 수 있다는 점을 고려해야 합니다.
    함수가 로컬 함수에 대해 4Kb 이상을 사용하는 경우 스택 메모리를 제공하기 위해 유틸리티 함수가 호출됩니다. 이것은 네이티브의 가혹한 진실이며 제거할 수 없습니다.

  2. SelfCPU는 호출을 고려하지 않아야 합니다. 그렇지 않으면 단순히 TotalCPU를 복제하고 자체 명령의 시간이 호출된 함수의 시간에 의해 흐려질 것입니다.
    행에 대한 TotalCPU는 해당 행의 "시간"입니다.
 
Alain Verleyen :

항상 100%여야 하는 것 아닌가요? 또는 @global_initializations 및 @global_deinitializations도 고려하면 약간 더 적습니다.

102% 이상이 있습니다...(이력 데이터에 대한 빌드 3003).

이전 프로파일러에 따르면 기사 에 더 많은 것이 있을 수 있다고 나와 있습니다.

프로파일링은 각 함수가 호출된 횟수, 실행에 소요된 시간 등 중요한 통계를 제공합니다. 백분율 통계로 인해 약간 혼란스러울 수 있습니다. 여기서 통계는 함수의 중첩을 고려하지 않으므로 모든 백분율의 합이 100%보다 훨씬 크다는 것을 이해해야 합니다.

 
Vasiliy Pushkaryov :

이전 프로파일러에 따르면 기사 에 더 많은 것이 있을 수 있다고 나와 있습니다.

고맙습니다. 그러나 내가 이해하는 한 새 프로파일러에서는 상황이 달라져야 합니다. 변명은 허용되지 않습니다. 실수는 실수입니다.
 
Ilyas :
  1. 여는 괄호 - 일반적으로 여러 배치 지침과 특히 지역 변수 초기화에 걸쳐 있는 함수 프롤로그로 생각하십시오.
    함수의 지역 변수 볼륨에 주의를 기울일 가치가 있습니다. 호출된 변수의 인라인으로 인해 볼륨이 증가할 수 있다는 점을 고려해야 합니다.
    함수가 로컬 함수에 대해 4Kb 이상을 사용하는 경우 스택 메모리를 제공하기 위해 유틸리티 함수가 호출됩니다. 이것은 네이티브의 가혹한 진실이며 제거할 수 없습니다.

  2. SelfCPU는 호출을 고려하지 않아야 합니다. 그렇지 않으면 단순히 TotalCPU를 복제하고 자체 명령의 시간이 호출된 함수의 시간에 의해 흐려질 것입니다.
    행에 대한 TotalCPU는 해당 행의 "시간"일 뿐입니다.

1) 함수 본문에는 하나의 이중 변수만 선언됩니다(const bool 시뮬레이트된 함수 매개변수는 계산하지 않음).

2) 즉, 프로세서가 11개의 작업 도구 중 하나에 대해 iTime( m_symbol, PERIOD_CURRENT, 0 )을 수신한 시간의 55%입니다("m_CloseOnFirstTickOnly || m_OpenOnFirstTickOnly" 조건이 작동한 경우)?

아니면 "Functions by Calls" 모드를 의미합니까(표시하지 않았음)?


자세히 이야기하기 위해 나로서는 이해할 수 없는 결과로 재현 가능한 코드 스니펫을 만들도록 노력하겠습니다.

 

간단한 예제를 사용하여 프로파일러 데이터의 해석을 도와주시기 바랍니다.

 #include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

const bool Init = EventSetMillisecondTimer ( 1 );

void f()
{
   Sleep ( 1 );
}

void OnTimer ()
{
  _USAGE
  
  f();
   Sleep ( 2 );
}


모든 것이 미친 헛소리처럼 보입니다.

  • 수면(2)이 완전히 누락되었습니다.
  • 어떤 이유로 USAGE는 Sleep(1)보다 몇 배나 더 오래 살아남습니다.


열심히 들어가려고 하는데 아직 안나오네요.


ZY 수면 교체를 시도했습니다.

 void Sleep2( uint Interval )
{
   const ulong StartTime = GetMicrosecondCount ();
  
  Interval *= 1000 ;
  
   while ( GetMicrosecondCount () - StartTime < Interval)
    ;
}

#define Sleep Sleep2

이해할 수 없는 모든 프로파일러 값도 있습니다.

 
fxsaber # :

간단한 예제를 사용하여 프로파일러 데이터의 해석을 도와주시기 바랍니다.


모든 것이 미친 듯이 보입니다.

  • 수면(2)이 완전히 누락되었습니다.
  • 어떤 이유로 USAGE는 Sleep(1)보다 몇 배나 더 오래 살아남습니다.

MT4에서는 동일한 코드가 절대적으로 논리적인 결과를 생성합니다.


MT5에서 내가 무엇을 잘못하고 있습니까?

ZY MT4의 프로파일러가 있는 MT5의 마지막 빌드는 b2595(b2593 - 내부 컴파일러 오류가 발생하는 경우)입니다.

 
그리고 왜 당신이 작성한 코드가 실제로 실행되고 있는 코드와 같다고 생각합니까?

결과 코드의 과도한 최적화 및 혼합에 대해 몇 번이나 반복해야 합니까? 인라인된 접두사는 이를 명확하게 나타냅니다.

또한 샘플링 프로파일러가 통계를 수집할 시간이 없는 빈약한 코드에서 프로파일러 를 사용하는 것은 의미가 없습니다.

프로파일러는 극도로 최적화된 코드에서 통계적으로 상당한 비용이 많이 드는 위치를 효과적으로 찾고 소스 코드에 대한 한 줄 한 줄 가이드가 아닙니다.

코드가 실제 실행 파일과 거의 관련이 없기 때문입니다.




 
Renat Fatkhullin 프로파일러 를 사용하는 것은 의미가 없습니다.

프로파일러는 잔인하게 최적화된 코드에서 통계적으로 상당한 비용이 많이 드는 위치를 효과적으로 찾고 라인별 소스 코드 가이드가 아닙니다.

코드가 실제 실행 파일과 거의 관련이 없기 때문입니다.

이렇게 간단한 예제를 작성해야 했기 때문에 중요한 소스 코드로 전투 고문에서 프로파일러의 가치를 설명하는 것은 불가능했습니다.

위의 질문을 받았습니다. 어떻게 Sleep(1)에 들어가지만 Sleep(2)에는 들어가지 않을 수 있습니까? 나는 당신이 아무것도 시작하거나 시청하지 않았다고 확신합니다. 다만 당신의 대답을 박쥐에서 바로 썼습니다.

최적화가 비활성화된 경우에도 동일한 넌센스가 발생합니다. 또한, 이전 프로파일러는 아직 새로운 접근 방식이 없는 b2596에 있습니다. 연구하는데 시간을 보냈다...

 

스마트 옵티마이저는 두 개의 Sleep을 연속적으로 하나로 결합한다고 가정했습니다. 그러나 테스트 결과 그렇지 않은 것으로 나타났습니다.

 #include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

const bool Init = EventSetMillisecondTimer ( 1 );

void f()
{
   Sleep ( 1 );
}

ulong Temp;

void OnTimer ()
{
  _USAGE
  
  f();
  
   Temp += GetMicrosecondCount () - Temp;
  
   Sleep ( 2 );
}

void OnDeinit ( const int )
{
   Print (Temp);
}

수면(2)이 표시되지 않습니다.