borilunad , 모든 함수 호출은 추가 브레이크를 추가합니다. 따라서 최대 속도가 필요한 경우 한 단어 연산을 수행하는 모든 Request()를 제거해야 합니다. 사이클도 마찬가지입니다. 루프에서 조건을 테스트하는 것은 일련의 중첩된 if()보다 항상 훨씬 느립니다.
따라서 상호 배타적인 조건이라도 if(A || B || C || D) Action을 사용하면 더 좋습니다.
하지만 함수 호출을 피할 수는 없습니다. 이 시점에서 이러한 조건에 포함된 많은 데이터를 확인할 필요가 있습니다.
나는 계속 실험을 할 것이고, 아마도 무언가를 파헤칠 것입니다. 그러나 확산에 대한 통제는 없습니다! :)
그러나 else result=false 줄을 첫 번째 줄과 결합하는 것이 더 좋으며 실제로 속도에 영향을 미치지 않습니다. 그리고 일반적으로 A, B, C 및 D에 간단한 조건(수학적 함수 및 기타 종소리 호출 없이 최소한의 산술 연산 포함)이 포함되어 있으면 그러한 최적화에서 많은 성능 이득을 얻지 못할 것입니다( 물론, 이 구성은 수천만 번이 아니라 당신에 의해 실행됩니다). 그러나 코드 혼란은 상당할 수 있습니다.
나는 이미 한 지점에서 이것에 대해 모든 것이 합리적으로 접근해야 한다고 썼습니다. 어떤 이유에서인지 코드에 더 중요한 위치가 많이 있는 것 같으며, 최적화하면 성능이 크게 향상됩니다. 기본 알고리즘부터 시작해야 합니다. 대부분의 초보자는 TS 또는 미결 주문과 관련된 모든 조건의 모든 틱 에 대해 멍청한 확인을 합니다. 따라서 브레이크. 대부분의 경우 경계 조건만 확인하면 충분하지만, 예를 들어 높고 낮음이 특정 값에 도달하거나 새로운 막대가 나타납니다. 그리고 그 후에야 추가 확인을 수행하십시오.
게다가 리소스 집약적인 계산을 사용하는 경우 이러한 계산을 DLL로 전송하는 것에 대해 생각할 필요가 있습니다. 그렇지 않으면, 빌어먹을 MQL4에서 13분 동안 앉아서 기다리는 것은(비록 2-3분 안에 동일한 결과를 얻을 수 있지만) 결함이 있습니다. :)
그러나 else result=false 줄을 첫 번째 줄과 결합하는 것이 더 좋으며 실제로 속도에 영향을 미치지 않습니다. 그리고 일반적으로 A, B, C 및 D에 간단한 조건(수학적 함수 및 기타 종소리 호출 없이 최소한의 산술 연산 포함)이 포함되어 있으면 그러한 최적화에서 많은 성능 이득을 얻지 못할 것입니다( 물론, 이 구성은 수천만 번이 아니라 당신에 의해 실행됩니다). 그러나 코드 혼란은 상당할 수 있습니다.
나는 이미 한 지점에서 이것에 대해 모든 것이 합리적으로 접근해야 한다고 썼습니다. 어떤 이유에서인지 코드에 더 중요한 위치가 많이 있는 것 같으며, 최적화하면 성능이 크게 향상됩니다. 기본 알고리즘부터 시작해야 합니다. 대부분의 초보자는 TS 또는 미결 주문과 관련된 모든 조건의 모든 틱에 대해 멍청한 확인을 합니다. 따라서 브레이크. 대부분의 경우 경계 조건만 확인하면 충분하지만, 예를 들어 높고 낮음이 특정 값에 도달하거나 새로운 막대가 나타납니다. 그리고 그 후에야 추가 확인을 수행하십시오.
게다가 리소스 집약적인 계산을 사용하는 경우 이러한 계산을 DLL로 전송하는 것에 대해 생각할 필요가 있습니다. 그렇지 않으면, 빌어먹을 MQL4에서 13분 동안 앉아서 기다리는 것은(비록 2-3분 안에 동일한 결과를 얻을 수 있지만) 결함이 있습니다. :)
그러나 else result=false 줄을 첫 번째 줄과 결합하는 것이 더 좋으며 실제로 속도에 영향을 미치지 않습니다. 그리고 일반적으로 A, B, C 및 D에 간단한 조건(수학적 함수 및 기타 종소리 호출 없이 최소한의 산술 연산 포함)이 포함되어 있으면 그러한 최적화에서 많은 성능 이득을 얻지 못할 것입니다( 물론, 이 구성은 수천만 번이 아니라 당신에 의해 실행됩니다). 그러나 코드 혼란은 상당할 수 있습니다.
나는 이미 한 지점에서 이것에 대해 모든 것이 합리적으로 접근해야 한다고 썼습니다. 어떤 이유에서인지 코드에 더 중요한 위치가 많이 있는 것 같으며, 최적화하면 성능이 크게 향상됩니다. 기본 알고리즘부터 시작해야 합니다. 대부분의 초보자는 TS 또는 미결 주문과 관련된 모든 조건의 모든 틱에 대해 멍청한 확인을 합니다. 따라서 브레이크. 대부분의 경우 경계 조건만 확인하면 충분하지만, 예를 들어 높고 낮음이 특정 값에 도달하거나 새로운 막대가 나타납니다. 그리고 그 후에야 추가 확인을 수행하십시오.
게다가 리소스 집약적인 계산을 사용하는 경우 이러한 계산을 DLL로 전송하는 것에 대해 생각할 필요가 있습니다. 그렇지 않으면, 빌어먹을 MQL4에서 13분 동안 앉아서 기다리는 것은(비록 2-3분 안에 동일한 결과를 얻을 수 있지만) 결함이 있습니다. :)
borilunad , 모든 함수 호출은 추가 브레이크를 추가합니다. 따라서 최대 속도가 필요한 경우 한 단어 연산을 수행하는 모든 Request()를 제거해야 합니다. 사이클도 마찬가지입니다. 루프에서 조건을 테스트하는 것은 일련의 중첩된 if()보다 항상 훨씬 느립니다.
따라서 상호 배타적인 조건이라도 if(A || B || C || D) Action을 사용하면 더 좋습니다.
하지만 함수 호출을 피할 수는 없습니다. 이 시점에서 이러한 조건에 포함된 많은 데이터를 확인할 필요가 있습니다.
나는 계속 실험을 할 것이고, 아마도 무언가를 파헤칠 것입니다. 그러나 확산에 대한 통제는 없습니다! :)
그러나 else result= false 줄을 첫 번째 줄과 결합하는 것이 더 좋으며 실제로 속도에 영향을 미치지 않습니다. 그리고 일반적으로 A, B, C 및 D에 간단한 조건(수학적 함수 및 기타 종소리 호출 없이 최소한의 산술 연산 포함)이 포함되어 있으면 그러한 최적화에서 많은 성능 이득을 얻지 못할 것입니다( 물론, 이 구성은 수천만 번이 아니라 당신에 의해 실행됩니다). 그러나 코드 혼란은 상당할 수 있습니다.
나는 이미 한 지점에서 이것에 대해 모든 것이 합리적으로 접근해야 한다고 썼습니다. 어떤 이유에서인지 코드에 더 중요한 위치가 많이 있는 것 같으며, 최적화하면 성능이 크게 향상됩니다. 기본 알고리즘부터 시작해야 합니다. 대부분의 초보자는 TS 또는 미결 주문과 관련된 모든 조건의 모든 틱 에 대해 멍청한 확인을 합니다. 따라서 브레이크. 대부분의 경우 경계 조건만 확인하면 충분하지만, 예를 들어 높고 낮음이 특정 값에 도달하거나 새로운 막대가 나타납니다. 그리고 그 후에야 추가 확인을 수행하십시오.
게다가 리소스 집약적인 계산을 사용하는 경우 이러한 계산을 DLL로 전송하는 것에 대해 생각할 필요가 있습니다. 그렇지 않으면, 빌어먹을 MQL4에서 13분 동안 앉아서 기다리는 것은(비록 2-3분 안에 동일한 결과를 얻을 수 있지만) 결함이 있습니다. :)
일반적으로 가장 빠른 옵션은 다음과 같습니다.
그러나 else result= false 줄을 첫 번째 줄과 결합하는 것이 더 좋으며 실제로 속도에 영향을 미치지 않습니다. 그리고 일반적으로 A, B, C 및 D에 간단한 조건(수학적 함수 및 기타 종소리 호출 없이 최소한의 산술 연산 포함)이 포함되어 있으면 그러한 최적화에서 많은 성능 이득을 얻지 못할 것입니다( 물론, 이 구성은 수천만 번이 아니라 당신에 의해 실행됩니다). 그러나 코드 혼란은 상당할 수 있습니다.
나는 이미 한 지점에서 이것에 대해 모든 것이 합리적으로 접근해야 한다고 썼습니다. 어떤 이유에서인지 코드에 더 중요한 위치가 많이 있는 것 같으며, 최적화하면 성능이 크게 향상됩니다. 기본 알고리즘부터 시작해야 합니다. 대부분의 초보자는 TS 또는 미결 주문과 관련된 모든 조건의 모든 틱에 대해 멍청한 확인을 합니다. 따라서 브레이크. 대부분의 경우 경계 조건만 확인하면 충분하지만, 예를 들어 높고 낮음이 특정 값에 도달하거나 새로운 막대가 나타납니다. 그리고 그 후에야 추가 확인을 수행하십시오.
게다가 리소스 집약적인 계산을 사용하는 경우 이러한 계산을 DLL로 전송하는 것에 대해 생각할 필요가 있습니다. 그렇지 않으면, 빌어먹을 MQL4에서 13분 동안 앉아서 기다리는 것은(비록 2-3분 안에 동일한 결과를 얻을 수 있지만) 결함이 있습니다. :)
Paco가 제공하는 가장 빠른 옵션
매번 여러 값을 합산하는 것(즉, 불필요한 산술 연산 수행 )이 더 빠르다고 진지하게 생각하십니까? 내 버전에서 확인은 첫 번째 일치에서 끝납니다. 언급한 버전에서는 모든 값을 합산한 다음 합을 확인한 후에만 끝납니다.
또한 해당 옵션을 사용하려면 모든 조건을 미리 계산해야 합니다. 어떤 종류의 속도에 대해 이야기할 수 있습니까? 이것은 가장 느린 옵션입니다.
가속이 필요한 경우 비트 연산 을 시도할 수 있습니다.
저것들. 모든 변수를 int 유형으로 만듭니다(false=0). 그런 다음 비트별로 A|B|C...>0
가속이 필요한 경우 비트 연산을 시도할 수 있습니다.
저것들. 모든 변수를 int 유형으로 만듭니다(false=0). 그런 다음 비트별로 A|B|C...>0
그리고 아무도 실행 속도에 대해 제안된 옵션을 확인하지 않을 것입니까?
여기에서 스크립트를 가져갈 수 있습니다.
일반적으로 가장 빠른 옵션은 다음과 같습니다.
그러나 else result= false 줄을 첫 번째 줄과 결합하는 것이 더 좋으며 실제로 속도에 영향을 미치지 않습니다. 그리고 일반적으로 A, B, C 및 D에 간단한 조건(수학적 함수 및 기타 종소리 호출 없이 최소한의 산술 연산 포함)이 포함되어 있으면 그러한 최적화에서 많은 성능 이득을 얻지 못할 것입니다( 물론, 이 구성은 수천만 번이 아니라 당신에 의해 실행됩니다). 그러나 코드 혼란은 상당할 수 있습니다.
나는 이미 한 지점에서 이것에 대해 모든 것이 합리적으로 접근해야 한다고 썼습니다. 어떤 이유에서인지 코드에 더 중요한 위치가 많이 있는 것 같으며, 최적화하면 성능이 크게 향상됩니다. 기본 알고리즘부터 시작해야 합니다. 대부분의 초보자는 TS 또는 미결 주문과 관련된 모든 조건의 모든 틱에 대해 멍청한 확인을 합니다. 따라서 브레이크. 대부분의 경우 경계 조건만 확인하면 충분하지만, 예를 들어 높고 낮음이 특정 값에 도달하거나 새로운 막대가 나타납니다. 그리고 그 후에야 추가 확인을 수행하십시오.
게다가 리소스 집약적인 계산을 사용하는 경우 이러한 계산을 DLL로 전송하는 것에 대해 생각할 필요가 있습니다. 그렇지 않으면, 빌어먹을 MQL4에서 13분 동안 앉아서 기다리는 것은(비록 2-3분 안에 동일한 결과를 얻을 수 있지만) 결함이 있습니다. :)
그래서 더 빠릅니다.
다음과 같은 이야기를 기억했습니다.
"회사 이사회에서 2가지 질문이 있었습니다.
1. 싱크로파소트론을 구축하기로 결정.
2. 직원들을 위한 자전거 거치대를 만들기로 결정.
첫 번째 질문에 대한 토론은 1분 동안 진행되었으며,
2차 토론회는 2시간 넘게 이어졌다.