mql5 언어의 특징, 미묘함 및 작업 방법 - 페이지 49

새 코멘트
 
fxsaber :

if, else, for, do TAB 키를 누르면 단어 바로 뒤에 작은 추가 단어가 표시됩니다. 건물...


fir-trees.. 클래스, mql과 5년 간의 만남 후 - 알게 되었습니다.

 

제기된 한 가지 문제 에 대한 SD 대화의 결론.

문자열 변수에 값을 할당하는 것은 매우 비용이 많이 드는 작업입니다.

너무 비싸서 개발자가 컴파일러에서 이 점을 개선할 때까지 가능하면 피하는 것이 바람직하며 이는 곧 일어나지 않을 것 같습니다.


예를 들어 FIBO에서 매월 실제 틱으로 실행하면 약 100만 틱이 됩니다. 매 틱마다 PositionGetString 값을 가져와서 무언가와 비교하면 성능은 허용되지만 비교하기 전에 먼저 함수의 결과를 문자열 변수에 할당한 다음 비교하면 실행 시간이 1초 정도 증가합니다.


이것이 사소한 것 같으면 이것은 잘못된 비전입니다. 이러한 어드바이저가 수천 패스에 대한 최적화 모드에서 시작되면 이것이 추가됩니다. 두 번째 결과는 추가입니다. 대기 시간. 저것들. 무해한 문자열 할당은 추가를 유발할 수 있습니다. 최적화하는 동안 몇 시간을 기다려야 합니다. 조심하고 이 뉘앙스를 고려하십시오.


코드 기반에는 동일한 거래 논리의 다른 구현에서 이러한 실패를 감지할 수 있는 작은 도구가 있습니다. 빠른 코드를 작성하십시오.

 
fxsaber :

한 가지 문제에 대한 SD 대화의 결론이 제기 되었습니다.

문자열 변수에 값을 할당하는 것은 매우 비용이 많이 드는 작업입니다.

너무 비싸서 개발자가 컴파일러에서 이 점을 개선할 때까지 가능하면 피하는 것이 바람직하며 이는 곧 일어나지 않을 것 같습니다.


예를 들어 FIBO에서 매월 실제 틱으로 실행하면 약 100만 틱이 됩니다. 매 틱마다 PositionGetString 값을 가져와서 무언가와 비교하면 성능은 허용되지만 비교하기 전에 먼저 함수의 결과를 문자열 변수에 할당한 다음 비교하면 실행 시간이 1초 정도 증가합니다.


이것이 사소한 것 같으면 이것은 잘못된 비전입니다. 이러한 어드바이저가 수천 패스에 대한 최적화 모드에서 시작되면 이것이 추가됩니다. 두 번째 결과는 추가입니다. 대기 시간. 저것들. 무해한 문자열 할당은 추가를 유발할 수 있습니다. 최적화하는 동안 몇 시간을 기다려야 합니다. 조심하고 이 뉘앙스를 고려하십시오.


코드 기반에는 동일한 거래 논리의 다른 구현에서 이러한 실패를 감지할 수 있는 작은 도구가 있습니다. 빠른 코드를 작성하십시오.

고마워, 나는 이것이 가능하다고 생각하지 않았다. 향후 전개에 고려 예정

 

밤에 간단한 수수께끼, 왜 노란색 결과가 나오나요?

 struct INT
{
   int Array[];
  
  INT()
  {
     Print ( __FUNCTION__ ); // до сюда не дойдет
  }
};

void OnStart ()
{
  INT i = { 0 };
  
   Print ( ArrayResize (i.Array, 5 )); // -1
}
 
fxsaber :

밤에 간단한 수수께끼, 왜 노란색 결과가 나오나요?

구조가 생성자가 아닌 0으로 채워지기 때문에 배열 구조가 잘못 초기화되고 arrayresize 가 이러한 배열을 좋아하지 않으며 일반적으로 이러한 크기 조정에서 내 코드가 충돌합니다.
 
결합기 :
구조가 생성자가 아닌 0으로 채워지기 때문에 배열 구조가 잘못 초기화되고 arrayresize가 이러한 배열을 좋아하지 않으며 일반적으로 이러한 크기 조정에서 내 코드가 충돌합니다.

모든 사람이 그것에 대해 알고 있는 것이 좋습니다.

 
슬라바 :

GetMicrosecondCount를 의미합니다. 서버가 느려지는지 여부를 확실히 말할 수는 없습니다. 간접적인 영향을 미칠 수 있습니다. 따라서 시스템 기본 GetTickCount를 사용하는 것이 좋습니다.

GetMicrosecondCount는 코드 실행의 짧은 섹션을 측정하는 데 사용됩니다. 대규모 OnTick 집합의 실행을 측정하려면 GetTickCount가 여전히 더 좋습니다.

안정적인 결과를 얻은 후 GetTickCount 대신 GetMicrosecondsCount를 사용해 보십시오. 그럼 여기서 말하세요. 어쩌면 나는 아무렇지도 않게 걱정하고 있습니다.

귀하의 가설이 올바른 것으로 판명되었습니다. GetMicrosecondsCount에 대한 다중 호출은 테스터에서 끔찍한 제동을 일으킵니다. 그러나 GetTickCount 는 동일한 효과를 가집니다.
 
fxsaber :

제기된 한 가지 문제 에 대한 SD 대화의 결론.

문자열 변수에 값을 할당하는 것은 매우 비용이 많이 드는 작업입니다.

너무 비싸서 개발자가 컴파일러에서 이 점을 개선할 때까지 가능하면 피하는 것이 바람직하며 이는 곧 일어나지 않을 것 같습니다.


예를 들어 FIBO에서 매월 실제 틱으로 실행하면 약 100만 틱이 됩니다. 매 틱마다 PositionGetString 값을 가져와서 무언가와 비교하면 성능은 허용되지만 비교하기 전에 먼저 함수의 결과를 문자열 변수에 할당한 다음 비교하면 실행 시간이 1초 정도 증가합니다.


이것이 사소한 것 같으면 이것은 잘못된 비전입니다. 이러한 어드바이저가 수천 패스에 대한 최적화 모드에서 시작되면 이것이 추가됩니다. 두 번째 결과는 추가입니다. 대기 시간. 저것들. 무해한 문자열 할당은 추가를 유발할 수 있습니다. 최적화하는 동안 몇 시간을 기다려야 합니다. 조심하고 이 뉘앙스를 고려하십시오.


코드 기반에는 동일한 거래 논리의 다른 구현에서 이러한 실패를 감지할 수 있는 작은 도구가 있습니다. 빠른 코드를 작성하십시오.

 struct STRUCT
{
   string Str;
  
   string Get() const { return ( this .Str); }
};

void OnStart ()
{
  STRUCT Struct;
  
   Print (Struct.Str);
   Print (Struct.Get()); // Выполняется гораздо дольше, чем предыдущая строка
}
 
fxsaber :

문자열 변수에 값을 할당하는 것은 매우 비용이 많이 드는 작업입니다.

...

비교하기 전에 먼저 함수의 결과를 문자열 변수에 할당하고 비교하면 실행 시간이 약 1초 증가합니다.

내가 이해하는 한 문제는 할당 비용이 많이 드는 것이 아니라 컴파일러가 코드에서 이 추가 할당을 잘라내지 않아도 된다는 사실입니다. 저것들. 컴파일된 코드는 두 경우 모두 동일해야 합니다.
 
알렉세이 나보이코프 :
내가 이해하는 한 문제는 할당 비용이 많이 드는 것이 아니라 컴파일러가 코드에서 이 추가 할당을 잘라내지 않아도 된다는 사실입니다. 저것들. 컴파일된 코드는 두 경우 모두 동일해야 합니다.

이것은 사소한 문제입니다. 예, 컴파일러 최적화 프로그램은 아직 이러한 문자열 순간을 최적화할 수 없습니다. 그러나 속도 저하 문제는 정확히 문자열 할당에 있습니다.

컴파일러가 최적화할 수 없는 코드를 작성하되 할당을 하십시오. 그리고 브레이크를 봅니다.

그리고 함수를 통해 구조체의 문자열 필드를 읽는 예는 MT4/5에서 위치 속성 읽기가 구현되는 방식과 동일합니다.

MT4에서 동일한 OrderSymbol()은 MT5에서 구현되는 경우 브레이크입니다. 개발자는 링크를 통해 함수에 문자열을 전달하려고 합니다.

그래서 이런 글을 쓴다면

 if (( OrderSymbol () == Symb) && ( OrderMagicNumber == Magic))

일반 조건의 끝에서 OrderSymbol-조건을 푸시하는 것이 항상 더 좋습니다.


일반적으로 TesterBench를 사용하기 시작했을 때 갑자기 느려지는 것을 보았습니다.

1...424344454647484950515253545556...247
새 코멘트